Quand il y a des commentaires, ils sont au choix :
- triviaux (on m'a demandé de mettre des commentaires, je le fait),
- faux (/* vérifier que i est positif */ if (i == 0) ...);
- incompréhensible (j'ai déjà vu des commentaire en indhi ! (ben oui, je suis con je parle pas l'indhi couramment))
Des fois c'est les trois à la fois ! C'est d'ailleurs le cas du "vérifier que I est positif". Le commentaire ferait mieux d'expliquer le pourquoi du test plutôt que le détail ; genre "éviter une division par zéro".
Une certitude, les commentaires ne sont jamais maintenu. On est pressé la prod est plantée ! Ou bien le commercial a vendu ça pour hier et on est samedi, il est 23h00 !
Donc oui aux commentaires d'API, à l'explication de l'algo subtil etc.
Par contre et par pitié, épargnons nous les commentaire qui ne servent à rien si ce n'est à doubler le nombre de ligne à lire, puis à décider qui du commentaire ou du code à raison !
Par principe un code bien écrit doit être lisible. (bon en assembleur ça se complique)
Le prétexte genre "c'est du C donc je peux pas faire lisible" se traduit en "je suis pas bon, je ferai mieux de faire du cobol ça limitera les dégâts". (perso, je programme aussi en cobol, le moins souvent possible, soyons honnêtes :) )
# Dans la vraie vie
Posté par bertrand . En réponse au message Commentaires dans le code. Évalué à 10.
Quand il y a des commentaires, ils sont au choix :
- triviaux (on m'a demandé de mettre des commentaires, je le fait),
- faux (/* vérifier que i est positif */ if (i == 0) ...);
- incompréhensible (j'ai déjà vu des commentaire en indhi ! (ben oui, je suis con je parle pas l'indhi couramment))
Des fois c'est les trois à la fois ! C'est d'ailleurs le cas du "vérifier que I est positif". Le commentaire ferait mieux d'expliquer le pourquoi du test plutôt que le détail ; genre "éviter une division par zéro".
Une certitude, les commentaires ne sont jamais maintenu. On est pressé la prod est plantée ! Ou bien le commercial a vendu ça pour hier et on est samedi, il est 23h00 !
Donc oui aux commentaires d'API, à l'explication de l'algo subtil etc.
Par contre et par pitié, épargnons nous les commentaire qui ne servent à rien si ce n'est à doubler le nombre de ligne à lire, puis à décider qui du commentaire ou du code à raison !
Par principe un code bien écrit doit être lisible. (bon en assembleur ça se complique)
Le prétexte genre "c'est du C donc je peux pas faire lisible" se traduit en "je suis pas bon, je ferai mieux de faire du cobol ça limitera les dégâts". (perso, je programme aussi en cobol, le moins souvent possible, soyons honnêtes :) )
J'espère n'avoir froissé personne.