Il y a les commentaires définis tels quels par la syntaxe du langage, qui sont selon moi moyennement utiles, et les commentaires implicites: les types des paramètres (et des variables), les noms des classes, des méthodes, des fonctions, des paramètres et des variables.
Perso, j'ai remarqué que quand une fonction ne fait qu'une chose, elle à tendance à être réellement triviale. Après, il faut que je précise que j'aime C++: typage fort (tant qu'on utilise pas la syntaxe du C, bien sûr) et Orienté Objet, sans imposer ce dernier.
En général, je maintiens un diagramme des classes, et mes classes sont fortement spécialisées, idem pour les méthodes et fonctions. Du coup, passer les 50 lignes est vraiment une chose rare, d'autant que le moindre duo de ligne qui se ressemble est envoyé dans sa méthode propre.
Enfin, j'utilise quand même les commentaires explicites, pour préciser les parties des contrats de mes méthodes que je peux pas préciser avec la syntaxe de C++, ainsi que les lignes à la syntaxe barbare (quoique je préfère simplifier ces lignes plutôt que de les commenter).
Donc, oui, je pense faire du code lisible malgré qu'il soit peu commenté.
Ce que je n'apprécie pas avec les commentaires, c'est… il faut les maintenir, et ça paraphrase trop souvent le code.
D'un autre côté, un langage sans typage, je comprend l'intérêt: comment faire pour savoir que tel paramètre est censé ne pas être modifié par la méthode sans typage? Commenter…
En fin de compte, je pense plus ou moins la même chose des commentaires que de la notation hongroise pour les noms de variables: inutiles avec certains langages/projets, vitaux avec d'autres, et utiles en fonction du degré d'expressivité du langage et de la complexité du projet (un projet avec une grosse contrainte sur la perf, et donc hyper optimisé sera illisible sans commentaires peu importe le langage)
# Il y a plusieurs formes de commentaires.
Posté par freem . En réponse au journal To comment or not to comment. That is the question.. Évalué à 8.
Il y a les commentaires définis tels quels par la syntaxe du langage, qui sont selon moi moyennement utiles, et les commentaires implicites: les types des paramètres (et des variables), les noms des classes, des méthodes, des fonctions, des paramètres et des variables.
Perso, j'ai remarqué que quand une fonction ne fait qu'une chose, elle à tendance à être réellement triviale. Après, il faut que je précise que j'aime C++: typage fort (tant qu'on utilise pas la syntaxe du C, bien sûr) et Orienté Objet, sans imposer ce dernier.
En général, je maintiens un diagramme des classes, et mes classes sont fortement spécialisées, idem pour les méthodes et fonctions. Du coup, passer les 50 lignes est vraiment une chose rare, d'autant que le moindre duo de ligne qui se ressemble est envoyé dans sa méthode propre.
Enfin, j'utilise quand même les commentaires explicites, pour préciser les parties des contrats de mes méthodes que je peux pas préciser avec la syntaxe de C++, ainsi que les lignes à la syntaxe barbare (quoique je préfère simplifier ces lignes plutôt que de les commenter).
Donc, oui, je pense faire du code lisible malgré qu'il soit peu commenté.
Ce que je n'apprécie pas avec les commentaires, c'est… il faut les maintenir, et ça paraphrase trop souvent le code.
D'un autre côté, un langage sans typage, je comprend l'intérêt: comment faire pour savoir que tel paramètre est censé ne pas être modifié par la méthode sans typage? Commenter…
En fin de compte, je pense plus ou moins la même chose des commentaires que de la notation hongroise pour les noms de variables: inutiles avec certains langages/projets, vitaux avec d'autres, et utiles en fonction du degré d'expressivité du langage et de la complexité du projet (un projet avec une grosse contrainte sur la perf, et donc hyper optimisé sera illisible sans commentaires peu importe le langage)