Du C ou des langages encore plus anciens, ça demande beaucoup de commentaires pour qu'une personne extérieure comprenne ce que fait le programme en lisant le code.
Avec les langages modernes et orientés objet, avec une bonne sémantique métier, un architecture MVC, une implémentation judicieuse des modèles de conception classiques, etc... on arrive à faire du code qui demande peu de commentaires.
Comme évoqué précédemment, il faut surtout bien documenter les classes et les méthodes, et exposer un maximum de fonctionnalités de l'application sous forme d'API. De cette façon, ça oblige à concevoir l'application correctement, en faisant une bonne abstraction du langage, et en pensant soigneusement la couche métier.
Comme ça, avec simplement la documentation des méthodes et un bon document d'architecture, celui qui lit le code s'y retrouve.
Pour ne parler que du code lui-même (donc valable également en C, etc...), il faut attacher extrêmement d'importance à la sémantique des variables et des fonctions. Trop souvent on n'y fait pas attention, on met des noms de variable ésotériques (tmp_ceci, machin2, testCnx,...)
A moins de faire de l'embarqué ou autres domaines spécifiques, ça ne pèse pas lourd de mettre des noms de variables ou de fonctions explicites ! Pas d'abréviations, respect de la notation Camel ("maSuperFonctionQuiDéchire"), etc...
Enfin, en ce qui concerne les commentaires purs, en milieu de code, bien différencier les portions de code "métier", c'est à dire celles qui constituent le coeur de l'application, des portions de code "générique" (ex: ouverture et lecture d'un fichier, tri d'un tableau,...). Ces dernières portions, si elles sont proprement écrites, peuvent déjà être lues par un bon programmeur. Inutile de s'y attarder. En revanche, les portions de code métier doivent impérativement être commentées, même si elles sont triviales. Si ces portions ne sont pas commentées, essayer d'étudier l'application pour un développeur tiers revient à faire de la rétro-ingénierie sur ces portions ; le rôle des commentaires, c'est justement d'éviter cela.
Mais ne t'étonnes pas qu'en début de formation, on te demande de tout commenter. A ce niveau, ça revient à écrire l'algorithme, exprimer ce que tu as en tête au moment où tu codes. Au fil du temps, naturellement tu arrêteras de commenter ce qu'il n'est pas nécessaire de commenter.
# ça dépend aussi du langage
Posté par santos . En réponse au message Commentaires dans le code. Évalué à 3.
Avec les langages modernes et orientés objet, avec une bonne sémantique métier, un architecture MVC, une implémentation judicieuse des modèles de conception classiques, etc... on arrive à faire du code qui demande peu de commentaires.
Comme évoqué précédemment, il faut surtout bien documenter les classes et les méthodes, et exposer un maximum de fonctionnalités de l'application sous forme d'API. De cette façon, ça oblige à concevoir l'application correctement, en faisant une bonne abstraction du langage, et en pensant soigneusement la couche métier.
Comme ça, avec simplement la documentation des méthodes et un bon document d'architecture, celui qui lit le code s'y retrouve.
Pour ne parler que du code lui-même (donc valable également en C, etc...), il faut attacher extrêmement d'importance à la sémantique des variables et des fonctions. Trop souvent on n'y fait pas attention, on met des noms de variable ésotériques (tmp_ceci, machin2, testCnx,...)
A moins de faire de l'embarqué ou autres domaines spécifiques, ça ne pèse pas lourd de mettre des noms de variables ou de fonctions explicites ! Pas d'abréviations, respect de la notation Camel ("maSuperFonctionQuiDéchire"), etc...
Enfin, en ce qui concerne les commentaires purs, en milieu de code, bien différencier les portions de code "métier", c'est à dire celles qui constituent le coeur de l'application, des portions de code "générique" (ex: ouverture et lecture d'un fichier, tri d'un tableau,...). Ces dernières portions, si elles sont proprement écrites, peuvent déjà être lues par un bon programmeur. Inutile de s'y attarder. En revanche, les portions de code métier doivent impérativement être commentées, même si elles sont triviales. Si ces portions ne sont pas commentées, essayer d'étudier l'application pour un développeur tiers revient à faire de la rétro-ingénierie sur ces portions ; le rôle des commentaires, c'est justement d'éviter cela.
Mais ne t'étonnes pas qu'en début de formation, on te demande de tout commenter. A ce niveau, ça revient à écrire l'algorithme, exprimer ce que tu as en tête au moment où tu codes. Au fil du temps, naturellement tu arrêteras de commenter ce qu'il n'est pas nécessaire de commenter.