Cela dit, un bon code doit pouvoir se décrire de lui-même, les commentaires n'étant que la cerise sur le gâteau, le moyen d'expliquer des algorithmes pas forcément évidents.
En ce qui me concerne, j'apporte beaucoup d'importance à découper mon code en de multiples petites fonctions, chaque fonction étant liée à 1 idée ou 1 action, et inversement.
Je fais aussi très attention au noms que je donne à ces fonctions et au noms des varibles. De cette manière, si je lis un bout de code où le rôle de chaque fonction appelée et la raison d'être de chaque variable sont décrits par leurs noms, il y a de forte chance que je le comprenne sans ambiguité. Si en plus le code est clairement indenté, espacé, joli à regarder, alors là c'est presque de la littérature.
Je ne dis pas que les commentaires n'ont pas d'importance, je dis simplement qu'il ne faut pas non-plus en abuser et surtout les utiliser à bon escient. Je préfère, par exemple, expliquer pourquoi j'utilise la fonction non-blonquante waitpid dans une boucle plutôt que directement la fonction bloquante wait (c'est parce que sous Linux, les signaux ne sont pas enfilés) plutôt que d'écrire un gros cartouche au début du gestionaire du signal SIGCHLD pour dire que le paramètre d'entrée signal c'est l'identifiant du signal géré ...
Dans la série, je-ne-commente-pas-n'importe-comment-à-tour-de-bras : IMHO, il vaut bien mieux documenter à part l'architecture des données du programme et la manière dont elles évoluent ainsi que les paradigmes et réactions de ce programme, plutôt que de commenter chaque ligne du code au risque de le rendre illisible.
En clair, les commentaires c'est bien, en abuser ça craint ;)
[^] # Re: Un cri de désespoir du développeur d?un projet Open Source.
Posté par Yoann A. . En réponse à la dépêche Un cri de désespoir du développeur d'un projet Open Source.. Évalué à 1.
En ce qui me concerne, j'apporte beaucoup d'importance à découper mon code en de multiples petites fonctions, chaque fonction étant liée à 1 idée ou 1 action, et inversement.
Je fais aussi très attention au noms que je donne à ces fonctions et au noms des varibles. De cette manière, si je lis un bout de code où le rôle de chaque fonction appelée et la raison d'être de chaque variable sont décrits par leurs noms, il y a de forte chance que je le comprenne sans ambiguité. Si en plus le code est clairement indenté, espacé, joli à regarder, alors là c'est presque de la littérature.
Je ne dis pas que les commentaires n'ont pas d'importance, je dis simplement qu'il ne faut pas non-plus en abuser et surtout les utiliser à bon escient. Je préfère, par exemple, expliquer pourquoi j'utilise la fonction non-blonquante waitpid dans une boucle plutôt que directement la fonction bloquante wait (c'est parce que sous Linux, les signaux ne sont pas enfilés) plutôt que d'écrire un gros cartouche au début du gestionaire du signal SIGCHLD pour dire que le paramètre d'entrée signal c'est l'identifiant du signal géré ...
Dans la série, je-ne-commente-pas-n'importe-comment-à-tour-de-bras : IMHO, il vaut bien mieux documenter à part l'architecture des données du programme et la manière dont elles évoluent ainsi que les paradigmes et réactions de ce programme, plutôt que de commenter chaque ligne du code au risque de le rendre illisible.
En clair, les commentaires c'est bien, en abuser ça craint ;)