Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Tout à fait, du coup tu réitère : mise à jour des specs, PUIS développement sans commentaire, ou tu fais du refactoring avec les bons renommages afin de conserver une lisibilité et une compréhension correcte de ton codeEnvoyé par lod101
Rien n'est figé...sauf peut être les commentaires qui peuvent (trop) rapidement ne plus être maintenus et polluer le code
ça dépend fortement du contexte.
Dans mon contexte j'ai du faire un bout de programme qui va interroger une centrale de réservation en ligne bien particulière. Heureusement que j'avais prévu qu'un jour qu'aurais certainement à me connecter à une deuxième voir d'interriger plusieurs centrales pour un même client. ça m'a évité d'avoir à revoir ton mon code pour l'adapter. ça m'a éviter de devoir faire une MAJ de structure dans la base de données 1 an après et d'avoir à refaire une installation chez chaque client.
Mes tutoriels
Avant de poster :
- F1
- FAQ
- Tutoriels
- Guide du développeur Delphi devant un problème
L'argument sur l'incohérence entre un commentaire obsolète et le code commenté vaut aussi pour un code
non commenté qui n'est pas forcément bien écrit et les variables/méthodes bien nommées. Il faudra aussi
lire le code en détail pour savoir ce qu'il fait.
De plus, je l'ai déjà dit dans un post précédent, on n'est pas dans Matrix : c'est quand même plus facile
de lire un ensemble de commentaire en français que de lire un test unitaire ou une fonction.
En français il est possible qu'on ait des expressions ambiguës, déjà le post de cet article dit je cite: "le débutant doit éviter l'abstrait, et toujours opter pour le concret" ça veut dire quoi?
Avec les tests on sait avec précision comment utiliser le code, ce que le code fait, et si le code marche. On fait ainsi d'une pierre trois coups. C'est vrai le prix à payer est la complexité relative à écrire ou à lire un test par rapport à un langage naturel. Mais je trouve que le rapport qualité/prix est très acceptable!
Tout à fait, sauf que dans tous les cas tu dois pouvoir faire confiance au code, donc il doit être bien écrit, s'il est mal écrit avec ou sans commentaire c'est problématique donc la règle est d'écrire du bon code pour augmenter le degré de confiance
Si dans tous les cas tu dois lire le code, autant passer du temps à faire du bon code qu'à le commenter
==> les commentaires restent superflux et ont tendance au final à déservir, trop souvent un contournement pour justifier un code bancale
Je trouve la cinquième règle bizarre:
"Règle numéro cinq, les débutants doivent à tout prix éviter le copier/coller. Sauf, évidemment, s'ils veulent copier le code d'un programme qu'ils ont écrit."
Je trouve plutôt qu'on ne doit pas faire copier/coller pour un code qu'on a écrit. Mais si on a un code dont on n'a pas le contrôle, pour réutiliser on peut être contraint de faire copier/coller, parce qu'on ne peut pas se permettre de refactorer un code si l'auteur de ce code ne nous donne pas le droit de le faire.
Peut-être qu'un code propre permet d'éviter les commentaires.
Mais tous les codes sont-ils propres ?
Souvent il vaut mieux avoir un commentaire obsolète que rien du tout : il donne au moins un aperçu de ce qu'est sensé faire le code & permet de relire plus facilement ledit code.
J'ai eu trop souvent l'occasion de relire des programmes (que ce soit en impératif : CoBOL, ForTran, pascal, C...) ou en machins graphiques (LabView, par exemple). Sans commentaires, ces programmes étaient illisibles.
Pourquoi étaient-ils aussi mal écrits ? C'est une autre question, qui est hors sujet, puisque je ne connais pas l'historique de ces programmes. Mais ça montre l'importance de commentaires.
Sans compter que, même dans un code pas vraiment salopé, un commentaire peut expliquer pourquoi on a utilisé telle ou telle façon de faire à cet endroit précis du programme. Quand on (se) relit quelques semaines ou quelques mois plus tard, c'est précieux. Une suite d'instructions ne suffit pas à saisir l'intérêt de l'une d'elles en particulier.
« Un peuple qui est prêt à sacrifier un peu de liberté contre un peu de sécurité, ne mérite ni l'une, ni l'autre, et finira par perdre les deux. »
Attribué indistinctement à :
Thomas Jefferson
Benjamin Franklin
Albert Einstein !
On parle de règle pour un jeune développeur donc quitte à le "formater" aux bonnes pratiques autant qu'il commence de suite à faire du "bon code" sans avoir besoin de commentaires plutot que de faire du code qui serait illisible sinon.
Maintenant biensûr qu'il n'y a pas une seule règle pour faire du code propre et on ne pas réduire un code propre à un code sans commentaire :p
Donc si on reprend un historique d'un code non propre, biensûr qu'il vaut mieux avoir qques commentaires plutot que rien du tout (je vois les gros pavés de codes illisibles avec plein de conditions, etc.... à évite rà tout prix mais lorsqu'ils ont été fait y'a 10 ans, si y'a pas de commentaires en effet, c'est casse tête assuré....mais bon même avec des commentaires ça sera torture de neurones, juste que ça amène un minimum d'abstraction qui permet de souffler un peu...attention tout de même au degré de confiance à y apporter)
Entièrement OK pour dire que quand on fait un choix arbitraire ou qui peut sembler déroutant, le commentaire demeure bien utile, mais ce sont des cas rares, le commentaire ne doit pas réexpliquer pourquoi et comment tu codes, si le code est propre, tu te replon,ges et remémores rapidement ce que tu as pu développer auparavant, pas besoin de commentaires ==> la journalisation des modifications ne se fait pas par commentaires mais des outils comme CVS sont fort utiles pour ça (se souvenir qui a fait quoi, et pourquoi via les notes de commits si nécessaire)
Ahhh, ça fait du bien de lire ça...
@kisitomomotene et @deuz59. Juste une dernière question car je suis sur le cul quand je vous lis (apparemment on n'est pas sur la même longueur d'onde, on ne se comprend pas et on interprete mal à tour de rôle nos exemples). Est-ce que vous commentez votre code ou pas ? Si vous me répondez "oui" (même un petit), "oui ça dépend faut voir la complexité de l'algo", bon je nous considère pas définitivement perdus. Si vous me dite "non" et persistez avec "le code se suffit à lui même" alors là je vous considère définitivement perdus...
Je répète "les commentaires font parties des règle de codages"
http://www.oracle.com/technetwork/ja...41999.html#385
http://google-styleguide.googlecode....e.xml#Comments
http://en.wikipedia.org/wiki/Coding_conventions
entre autres...
Je ne crois pas coder salement, mais je suis content, quand je relis un programme, même si j'en suis l'auteur, d'avoir un bout de commentaire en début de procédure qui m'en résume le but, qui récapitule le rôle des paramètres (num:integer, par exemple, ne me dit plus rien au bout de quelques mois. Le commentaire me rappelle s'il s'agit du numéro d'un individu, d'un objet, d'un fichier... Et s'il n'y a qu'une variable num dans mon programme, il n'y a aucune raison de lui mettre un nom plus long.), s'il y a des effets de bords ou des conditions d'utilisation, quel est le sens de la valeur éventuellement retournée...
Bref, une aide précieuse en cas de débogage ou d'évolution du code. Même si j'ai déjà eu l'occasion d'apporter une modification à mon code sans l'avoir mentionnée dans le commentaire.
« Un peuple qui est prêt à sacrifier un peu de liberté contre un peu de sécurité, ne mérite ni l'une, ni l'autre, et finira par perdre les deux. »
Attribué indistinctement à :
Thomas Jefferson
Benjamin Franklin
Albert Einstein !
Pourquoi pas ? Ce que tu dis semble plutôt prouver le contraire.
Une autre règle que je donne à un débutant:
- "N'écris jamais de code bidon"
- "Oui mais c'était juste pour tester le ...."
- "... On dit toujours ça mais tôt ou tard par ou flemme on le réutilise direct sans correction. Et donc ta classe Test et ta méthode fonctionTest() qui est en O(n3) il vaut mieux prendre un peu plus de temps pour l'écrire correctement, même si à l'origine c'était juste pour tester un truc."
- "Promis, je recommencerais plus !"*
(*) cette dernière phrase ne s'est que trop rarement vérifiée
Linux > *
Je te rassure, j'ai fait et il peut m'arriver de continuer à faire du code pourri, je me souviens de mes récents débuts où je pensais bien faire et par manque d'expérience, c'était tout le contraire en terme de lisibilité, maintenabilité de code...et là oui, j'étais obligé de mettre des commentaires, bien utiles pour m'y retrouver, mais même avec ces commentaires dur dur de s'y retrouver dans le code.....Ahhh, ça fait du bien de lire ça...
@kisitomomotene et @deuz59. Juste une dernière question car je suis sur le cul quand je vous lis (apparemment on n'est pas sur la même longueur d'onde, on ne se comprend pas et on interprete mal à tour de rôle nos exemples). Est-ce que vous commentez votre code ou pas ? Si vous me répondez "oui" (même un petit
Je répète "les commentaires font parties des règle de codages"
http://www.oracle.com/technetwork/ja...41999.html#385
http://google-styleguide.googlecode....e.xml#Comments
http://en.wikipedia.org/wiki/Coding_conventions
entre autres...
le pb c'est que c'est pas évident de reconnaitre du bon et du mauvais code, rien que ce débat en est la preuve, et c'est l'expérience (sa propre expérience, confrontée à d'autres par exemple dans la lecture de l'ouvrage précédemment cité) qui permet d'évoluer dans la bonne direction
C'est pour ça qu'aujourd'hui à une personne moins expérimentée je ne donnerais pas comme une des règles principale de commenter, commenter, commenter, à moins qu'elle ne développe une API où dans ce cas la javadoc à davantage d'intérêt par exemple...
De mon côté vu que la question tourne sur mes habitudes perso, je m'efforce désormais en effet à faire en sorte qu'il n'y ai pas besoin de commentaires, et cela est bénéfique à différents niveaux car ça force à être plus précis donc plus lisible dans ce que l'on code. Je garde les commentaires pour justifier un choix arbitraire ou pour mettre en garde s'il y une grosse particularité (exemple récent : du code généré automatiquement dont les noms de classes ou méthodes qui figurent sont renseignés dans un fichier texte servant à la génération ==> pour la classe et les méthodes concernées, un petit commentaire qui indique que le renommage impactera ce point en particulier est utile car non détecté par l'IDE)
Outre les commentaires, et sans blamer les auteurs car en effet il faut être sensibilisé au préalable (je me répète mais il y a encore qques années, je faisais pareil, voir pire), d'où le principe de règles à communiquer aux débutants ainsi qu'à toute l'équipe ==> je m'arrache les cheveux à chaque fois que je tombe sur du code qui me demande à devoir dérouler tout l'algorithme en détail, y compris des préoccupations qui ne devraient pas me concernées, pour savoir ce qui est fait et où je dois intervenir dans le code
==> il n'y a pas de recette miracle, mais le livre que je cite précédemment me semble pertinent pour apprendre à mieux coder, ne serait-ce par toutes les bonnes questions à se poser qu'il permet de mettre à plat
+1
==> cette vision des choses met en avant une des raisons pour laquelle justement le code n'est pas lisible
==> il est sous entendu "je choisi des noms de variables plus explicites pour les distinguer les une des autres", c'est en partie vrai, mais le but est d'abord d'expliciter la variable en question. Que signifie "num" ? il peut signifier tout et n'importe quoi, trop vague et subjectif (numéro de telephone, numero de secu, numero du loto, ...) Alors qu'en nommant de façon plus précise comme 'numeroDeTelephone', plus de confusion possible (je vous vois déjà me dire : ça va faire des noms a rallonge, perte de lisibilité ...la lisibilité ne s'appuie pas que sur la densité, mieux vaut un peu plus dense mais compréhensible qu'un condensé de code totalement illisible...on pourrait faire le parallèle avec le langage SMS...)
Vous oubliez une raison valable de ne pas préciser plus avant dans le code le sens du nom de la variable : la réutilisation du code.
Si ma procédure peut être utilisée indifféremment pour un numéro d'ordre, de sécu, de SIRET..., alors je ne peux pas le préciser dans le code, avec le nom de la variable. Le commentaire peut lever des ambigüités. Car même l'appel de la procédure ou fonction peut ne pas le permettre.
Et je préfère un code trop commenté, quitte à ne pas lire tous les commentaires, quand je n'en ai pas besoin, que le contraire.
Ceci dit, tout ça relève de la querelle d'expert.
Et je suis d'accord que quand le code est clair...
« Un peuple qui est prêt à sacrifier un peu de liberté contre un peu de sécurité, ne mérite ni l'une, ni l'autre, et finira par perdre les deux. »
Attribué indistinctement à :
Thomas Jefferson
Benjamin Franklin
Albert Einstein !
tout à fait, sujet complexe et subjectif...la notion de bon code est délicate, c'est pourquoi il convient de s'entendre avant tout sur ce que c'est en consensus en début de projet en fixant les règles à suivre (rien que le type de langage apporte des contraintes ou spécificités pouvant justifier une règle appropriée qui le serait moins pour un autre langage)...ceci dit ce sont tjrs les même bonnes questions qu'il faudra se poser et on est tous d'accord pour dire qu'on se pose plein de questions, mais seule l'expérience mettra en avant les vrais bonnes questions et les éléments de réponses pertinents...
Pour en revenir à ton "num", s'il s'agit d'une procédure très générique, elle n'aura donc aucun traitement spécifique induit par le fait que ton num soit un numéro d'ordre de sécu, ou SIRET, ceci dit si ces différents types peuvent justifier d'être passés en argument c'est qu'ils ont une caractéristique commune et le nom de la varibable num doit s'en inspirer
...ensuite si tu as une fonctionnalité moins générique qui réutilise, celle-ci sera nommée plus spécifiquement (pourquoi pas faire une procédure spécifique au SIRET qui finalement appellera "juste" cette procédure générique mais facilitera la compréhension du code)
Prenons l'exemple d'une méthode qui crédite un solde, on parlera bien de crédit à ajouter au solde même si au final cette méthode s'appuiera sur une procédure d'opération plus générique où là en effet, les variables manipulées ne se nommeront plus solde, ni crédit mais premiereOperande et secondeOperande (on aurait pu les nommer num1 et num2 mais cela aurait été moins précis/lisible à mon goût...on ne se refait pas)
==> il faut savoir utiliser la généricité mais ne pas oublié que l'abstraction n'est pas une pratique visant à rendre tout abstrait à tel point qu'on perd pied vis-à-vis du concret, mais bien à factoriser les choses en les regroupant par concepts. Au final, à un certain niveau de l'implémentation on retombe dans le concret et tout doit devenir plus explicite, afin que le développeur puisse justement "s'abstraire" de devoir tout analyser et comprendre lorsqu'il ne s'intéresse qu'à une partie précise du code)
==> une couche générique/abstraite reprend un concept bien particulier, le nommage des variables, méthodes, etc... doivent appartenir au langage de ce concept.
==> une fois cette couche développée, d'autres couches d'un niveau d'abstraction moindre s'appuieront dessus, etc..
==> si on doit s'attaquer à un concept particulier, on ne devrait pas avoir à décortiquer les concepts sur lesquels il s'appui
==> la problématique des mauvais nommages fait qu'on peut rapidement ne plus faire confiance, ou comprendre globalement ces autres couches et devoir "inutilement" les remettre en cause et les analyser à leur tour (les commentaires restent malheureusement superflux dans ce cas)
N'oubliez pas que les règles énoncées dans l'article sont pour les "programmeurs débutants".
Le problème que vous citez est un cas de "généralisation" du code, ce qui justement est interdit dans les règles ("le débutant doit éviter l'abstrait, et toujours opter pour le concret.").
Ca me rappelle la triade :
1. Make It Work
2. Make It Right
3. Make It Fast
Ici, le #1 serait ce que doit faire un programmeur débutant : un code fonctionnel, concret, sans chercher a "faire mieux".
Le #2 serait réservé au programmeur expérimenté : refactor, architectural patterns, généralisation, ...
Le #3 est l'apanage du hacker (dans le bon sens du terme) qui modifie les rouage internes du code pour l 'optimiser : tactical patterns, spécificité du langage / de la plateforme, ...
ALGORITHME (n.m.): Méthode complexe de résolution d'un problème simple.
Ca y'est j'ai enfin dégoté ta bible (en ligne). Pour ceux que ça interesse "http://www.scribd.com/doc/50311486/coder-proprement". J'te remercie d'avoir insisté autant.
J'ai enfin compris d'où venait ton acharnement à vouloir te passer des commentaires et je comprends enfin ton point de vue.
En effet, ce que dit Robert C. Martin est juste. Mais (y'a toujours un "mais"), pour moi, au quotidien cela reste un idéal, une utopie, de la théorie. Alors oui, j'essaie de tendre vers cet idéal mais malheureusement ma progression reste asymptotique.
Mes compétences, les langages que j'utilise ainsi que les outils m'empêchent d'écrire ce code qui "se suffit à lui-même".
Tous les jours je lutte contre mes "if" et mes "for" imbriqués et souvent je cède. Là oui je suis face à un echec et alors je commente. C'est mon dernier recours, ma dernière chance et la seule solution pour avoir un "bon code" à mes yeux.
Tous les jours je lis du code que je n'ai pas écrit, que j'arrive à comprendre, qui est reconnu bon et que je réutilise grâce aux commentaires. Je remercie l'auteur d'avoir commenté ces echecs.
Voilà pourquoi, en pratique, au quotidien, le commentaire me semble indispensable et être un critère de qualité.
Allez une p'tite réf : Jef Raskin - Comments Are More Important Than Code
http://queue.acm.org/detail.cfm?id=1053354
ou directement le pdf http://portal.acm.org/ft_gateway.cfm...53354&type=pdf
Mais attention, on ne peut en choisir que deux
+1
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager