Commentaires : Contraint de communiquer un code source, l'État l'envoie… sur du papier

education
opendata
opensource
Tags: #<Tag:0x00007f3d29a4ca28> #<Tag:0x00007f3d29a4c8e8> #<Tag:0x00007f3d29a4c7a8>

#42

Si on fait

if (erreur){
    /* gestion erreur */ 
   return; /* éventuellement, if/else sinon */
} 
/* exécution normale */ 

Ça te va ? :grin: Tu veux faire comment sinon (bloc try/catch ?) ? C’est obligatoire selon les langages (Go, en fonction des libs JS/node…).

Clair, ça vaut une faute grave ça. thedailywtf (même si c’est romancé) a son lot d’articles de ce genre.


#43

Oui même s’il faut essayer de faire ça le moins souvent possible. (dur je sais ^^)
C’est le if / else qui m’ennuie, à chaque fois j’ai l’impression que mon cerveau se retourne dans ma tête et malheureusement je vois ça très souvent. Le but c’est de pouvoir lire une fonction de haut en bas en comprenant tout de suite son déroulement, pas devoir la relire 2 fois pour voir le chemin “erreur” et le chemin “normal”


#44

Si Erreur faire ça sinon on fait ça
ou
Si c’est bon on fait ça sinon on fait ça

D’un point de vue logique c’est similaire (tout comme le “chemin erreur / normal”)

Après, c’est la façon de penser et l’angle d’approche qui est différente (d’un coté on considère qu’on redirige en cas d’erreurs, sinon on fait le déroulement normal, de l’autre, on considère qu’on fait le déroulement normal sauf si… Et à la limite, c’est plus “clair” niveau visibilité du chemin de faire les erreurs avant)


#45

Oui bien sûr au final ça revient au même mais l’importance avec le code c’est qu’un Humain le comprenne tout de suite, on doit pouvoir le lire comme un livre.
Quand tu fais un “Si Erreur sinon on fait ça” tu va d’abord regarder ce qu’il se passe en cas d’erreur alors que tu veux regarder ce que la fonction fait puis éventuellement ce qu’elle fait en cas d’erreur.
C’est plus un problème de lecture pas de logique en effet mais je considère que ceux qui font ça “réfléchisse à l’envers”, c’est très personnel comme opinion :wink:
Par contre comme dit plus haut un “Si erreur” avec une sortie de fonction est correcte car on voit tout de suite l’intention même s’il ne faut pas en abuser.


#46

C’est pour ça que je parle d’angle d’approche différente.

C’est “logique” et cohérent aussi, mais pas forcement la même façon d’aborder la chose

Un peu comme ceux qui font faire un while et d’autres une boucle for pour faire la même chose en pratique.

La façon de penser “à l’envers” est pas mauvaise, c’est juste la “moins courante” parmi les développeurs (et parfois à tord)


#47

Les premiers éléments d'analyse :

http://www.lemonde.fr/campus/article/2016/10/25/apb-les-questions-que-souleve-le-code-source_5020076_4401467.html