Oui indent est vieux
Néanmoins ces outils gèrent difficilement la segmentation du code, les mesures de sécurités, l'adhérence aux standards, ...
Un coding standard (CS) pourrait par exemple imposer «le return uniquement en fin de fonction» ... difficile de trouver un outil fiable pour ça. D'où l'intéret d'un (CS) et de la confiance en son équipe.
Tout à fait, c'est pourquoi, il faut toujours essayer justifier toujours quand il y a un doute, la pertinence d'un code qui peut être en contradiction (seulement en apparence ou pas) avec des standards. Mais après c'est aussi une question de temps, que l'on a pas toujours, il faut donc faire un effort de compréhension, avant de dire houlalala ca respecte pas les standards.Envoyé par photon57
Et là je parle uniquement dans le cadre d'une discussion sur un forum, dans un contexte professionnel, il faut respecter les standards, même s'ils ne nous "conviennent" pas, mieux encore presque obligation d'en discuter avec l'architecte.
Dernière modification par invite7863222222222 ; 14/12/2011 à 18h45.
Oui, à partir du moment que c'est correctement documenté et ponctuel. Si cela arrive trop souvent néanmoins il n'y a que deux solutions adapter les CS ou recadrer le codeur (dans le cadre d'un développement). Évidemment dès les départ je me suis placé dans le cadre d'un projet professionnel.
Non ce a quoi vous répondez concerne le cadre d'une discussion comme ici dans un forum.
Ecrire une doc, avant de poster sur un forum c'est pas envisageable, déjà quon a pas toujours le temps de justifier dans le message même.
Dernière modification par invite7863222222222 ; 14/12/2011 à 19h12.
OK ... mal compris le message.
Le but premier de mon message était simplement de faire remarquer qu'aucun CS n'est justifiable dans l'absolu mais toujours dans le cadre de son utilisation suite à :
Quant à poster du code sur forum ... c'est libre a priori. Mais comme c'est un forum on a youjours le temps de prendre son temps pour écrire.
Dans mon message je ne parlais justement pas de CS.
Ceci dit, le code faisant suite, me semble être néanmoins d'une qualité relativement professionnelle.
Dernière modification par invite7863222222222 ; 14/12/2011 à 19h43.
Je reprends en essayant d'être clair :
Dans le document, une instruction d'échappement pourrait aussi bien correspondre à un try/catch qu'un if/else ou même à un break ...
Il n'y a aucune justification qui ferait dans l'absolu préférer l'un à l'autre. Il s'agit d'un choix. Chacun peut faire celui qu'il trouve adéquat (avec plus ou moins de succès comme pour chaque choix). Mais ce choix n'est plus individuel dans le cadre d'un projet professionnel et il peut préférer pour des raisons de performances par exemple l'utilisation de la méthode tryparse (en C#) à un codage employant un bloc try et la méthode parse.
Non une instruction if n'est pas une séquence dechappement.
une séquence d'échappement permet de stopper le déroulement du programme c'est à dire de revenir à un nœud précédent du programme (en fournissant les valeurs de retour).
Un if permet un embranchement de diverses possibilités de chemins possibles.
Return, break, throw sont des instructions d'échappement.
Dernière modification par invite7863222222222 ; 14/12/2011 à 20h34.
Si le if n'est pas une séquence d'échappement, un bloc try/catch non plus alors ? ni le goto ? Ni le return (en C par exemple) ? En fait ça se limite au return qui renvoie des valeurs ?
Si. Ce qui compte c'est darreter le traitement et donc revenir à un nœud précédent.
Donc si je suis le raisonnement, un try/catch n'est pas une séquence d'échappement, uniquement throw et return (par exemple en java ou C#) ?
En fait non un Return nest pas obligé de retourner un valeur, on peut faire un simple : "return;"
Un break aussi.
Un try catch c'est pour traiteement (d'exception) pas un séquence d'échappement.
Ouf ... du coup je ne vois même plus pourquoi ce serait une justification pour préférer un style de codage par rapport à un autre ...
Car ça permet de mettre plus de sémantique dans le code, c'est à dire que plutôt d'avoir du code qui traite tous les cas mécaniquement, le code se base des des pré requis qui ont été codé ailleurs et (dans des modules qui ont ete fait pour repondre correctement a ces responsabilites) dont le développeur peut ne plus s'en soucier.
Ça permet d'avoir un code qui a une coherance globale où toutes les responsabilités ont ben été découpées.
Mais attention j'ai dit j'aime bien, et je rajoute jaime bien quand le probleme nest parfaitement apprehender je ne le deconseille meme dans mes autres cas, car à force de faire des implicites on peut ne plus savoir ce qu'on a voulu faire. Donc non je ne veux pas le présenter comme une panacée.
Dernière modification par invite7863222222222 ; 14/12/2011 à 22h02.
Annulé....
Dernière modification par invite7863222222222 ; 14/12/2011 à 22h08.
Mais je conçois que comme je lai justifié, c'est difficilement compréhensible donc communicable, moi il se trouve que ca ma aidé à améliorer la qualité de ce que j'écrivais, maitenant ca va pas etre obligatoirement le cas pour tout le monde, c'est juste je pense un "style", rien d'autre.
Dernière modification par invite7863222222222 ; 14/12/2011 à 22h18.
On peut donc éventuellement créer un CS (pour les langages et les architectures qui pourraient le supporter) avec ton argumentation. Après ça reste une affaire de goût.
PS: je ne vois pas en quoi ça rajoute de la sémantique au code, car au bout du compte un gestion avec des exceptions, try/catch (par ex en C#) est totalement similaire à des fonctions qui renvoient un code erreur et où la gestion des erreurs est faite par if/else (par ex en C).
Plus de sémantique, dans le sens où on crée des structures qui remplissent des fonctions et qui sont réutilisables.
Mais dans le fond je suis d'accord, toute la sémantique est contenue dans les instructions élémentaires.
Et je n'aborde pas dans les langages infinitaires, ils ne sont pas implémentables dans nos ordinateurs.
Dernière modification par invite7863222222222 ; 14/12/2011 à 22h39.
Pour re-préciser, et pour résumer : mon point n'était pas sur les exceptions en particulier mais plus sur le fait d'aller le plus rapidement aux instructions d'échappement en évitant de lister tous les cas. Mais encore une fois, je mets de gros warnings, ce n'est pas un principe général, et ça ne répond pas toujours correctement au besoin. Par exemple, imaginons qu'on ait en tête de pouvoir faire plus tard des cas spéciaux pour chacun des cas, dans cette situation, ça ne sert à rien et c'est contre productif, de simplifier en perdant de l'information juste pour pouvoir arriver rapidement aux instructions d'échappement, juste pour le principe, alors que plus tard, on va devoir à nouveau pouvoir lister tous les cas et faire des traitements spéciaux pour chacun d'eux. Autant perdre en simplicité, mais gagner en temps lorsqu'on devra faire évoluer le produit.
Dernière modification par invite7863222222222 ; 14/12/2011 à 23h38.
Dans la plupart des cas on appelle ça du sucre syntaxique.Plus de sémantique, dans le sens où on crée des structures qui remplissent des fonctions et qui sont réutilisables.
Mais dans le fond je suis d'accord, toute la sémantique est contenue dans les instructions élémentaires.
Et je n'aborde pas dans les langages infinitaires, ils ne sont pas implémentables dans nos ordinateurs
le tout est de citer les bonnes personnes
Ou encore, le raisonnement par l'absurde est équivalent à supposer que l'on : A ou non A.
Quand un code a pour fonction d'évaluer A et si on a un test qui détermine cette A, ca correspond à quelque chose de s'arrêter et de retourner la valeur. Ca sera parfois moins clair, si on attend la fin de la fonction pour retourner la valeur, si le role de la fonction est uniquement de retourner la valeur de A.
Dernière modification par invite7863222222222 ; 15/12/2011 à 07h17.
Je ne pense pas que le document que tu as joint aille jusque là ...
Ca donne une impression de code moins indéterministe car dans le cadre d'un programme informatique, les variables ne peuvent avoir qu'une seule valeur, quand on l'a trouvé, on la retourne. C'est pas plus bête que cela.
En fait c'est le cas contraire que je ne comprends pas, pourquoi forcer à attendre la fin d'une fonction pour retourner la valeur quand on est sur de l'avoir bien calculée à un moment et que ca n'est pas été trop compliqué de l'avoir. C'est juste cela qui me semble contre naturel.
Dernière modification par invite7863222222222 ; 15/12/2011 à 07h47.
??? je dois être un peu bête car je ne comprends pas ta phrase ... moins déterministe ???
Parce que justement ce n'est qu'une question de goût ... ou parfois de contraintes.
moins indéterministe j'ai corrigé.
Dans certains cas, ca ne vous parait toujours pas plus "naturel", alors. Ok tant pis.Parce que justement ce n'est qu'une question de goût ... ou parfois de contraintes.
Dernière modification par invite7863222222222 ; 15/12/2011 à 08h17.
Comme c'est une question de goût donc on ne peut pas dire que ce soit naturel (terme que je n'aime pas, quel est son contraire ? artificiel ? humain ? innaturel ? diabolique ?), en ce qui me concerne je dirais personnel. Je dirais même que ta proposition au post #18 est élégante et appropriée dans ce cas.
On peut toujours trouver des pours et des contres dans chacun des cas ... mettre fin à l'appel au plus vite dans un cas, maintenance facilitée dans l'autre ...
Ce qui me gène est la justification faite avec le document de Krivine.
Justement le fait que ce soit élégant, trouve sa justification, dans le fait que la séquence d'échappement est utilisée pour représenter un raisonnement par l'absurde.
ce qui le rend élégant pour moi est que la fonction tient en quelques lignes et que tout reste lisible.
Le document peut amener les gens à voir les choses différemment avec un oeil neuf et une compréhension révélée si tu veux ; ce n'est en aucun cas une justification à son utilisation ou non. Il faut garder le document dans son contexte.
Oui tant mieux c'est ce qui était recherché.que tout reste lisible.
