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
Discussion :
Ca résume un peu ce qui est dit dans ce bouquin, même s'ils mettent également en avant les commentaires: http://www.amazon.com/Art-Readable-C.../dp/0596802293
Je pense que tous les développeurs devraient lire ce bouquin, à titre personnel, il a grandement améliorer la lisibilité et la maintenabilité de mon code !
Non, je ne sais toujours pas à quoi peu servir une liste de serveurs dits "sous-connectés". terme qui pourrait laisser penser qu'on cherche des serveurs sous-utilisés, une question d'optimisation peut-être mais je ne peux que le supposer.Envoyé par germinolegrand
Hors contexte (car ce nom a peut-être un intérêt dans son contexte), j'aurais appelé la méthode à base de LessConnexionThan qui est ce que fait réellement le code si j'en crois tes commentaires. A la lecture par contre, server.second et server.first me font penser à une liste chaînée utilisée très bizarrement puisqu'on teste "second" pour récupérer "first".
et bien justement, les développeurs ne sont pas toujours expert dans le langage qu'ils doivent maintenir (demande leur avis à tous les développeurs C# à qui on a demandé de traduire du code Delphi).
Personnellement je lis bcp de C++ pour le traduire en Pascal (Delphi) ce qui me donne une connaissance très relative du C++ et des efforts constants pour le comprendre, dans 90% des cas c'est relativement simple, et il reste 10% de code abscons à base de conversion de type, de macro, de generic et cie qui rendent la lecture des plus confuse.
est il écrit en C++11 ?
A quand la fin de cette mode ideuse de commencer une accolade en fin de ligne en Java ? C'est moche, pas pratique, illisible, une perte de temps et finalement aucun véritable gain. Mais comme tout le monde le fait alors tout le monde le fait.....
Pourquoi c'est moche?
Pourquoi c'est pas pratique?
...
Et ce que je ne comprend pas le plus c'est pourquoi c'est une perte de temps?
Ça c'est ton avis, et moi je la trouve plus lisible, pratique.Le bon goût, c'est mon goût. En fait c'est une convention que l'on a prise comme habitude.
Ne serait-ce que parce que quand on génère la doc de code, si il y a pas de commentaires, il y a pas de documentation. Et une documentation bien générée, ça veut aussi dire, retrouver plus rapidement une brique logicielle ou même juste une fonctionnalité sans avoir systématiquement tout à expliquer au petit nouveau. Par exemple.
Les commentaires "Captain Obvious" sont parfois juste nécessaires pour faciliter une recherche d'informations dans la doc. Ce qui les rend souvent indispensables.
Ceci dit, je suis d'accord avec les conclusions qui suggèrent qu'un code est censé parler de lui-même.
Le truc aussi c'est comment le code va vieillir une solution propre ne l'est pas forcement dans 10 ans.
X personnes à passer dessus avec des logiques différentes certain qui font plus dans la fonction qui fait le café plutôt que des petites fonctions propres est réutilisable ....
Ensuite je suis d'accord avec sur le fait que générer la doc est quelques choses de très important parce qu'avant de trouver le bout de code que l'ont lise le bout de code que l'on cherche il faut déjà le trouver.
Et la doc word c'est lourd, pas toujours simple pour naviguer dedans et que dans le temps elle n'est plus forcement à jour.
Les commentaires ne sont pas la forcement pour l'équipe actuelle sur l'instant T mais plutôt pour les gens qui vont venir après ou pour les oublies dans le temps.
Et c'est toujours intéressant un petit commentaire du style cette partie sert à éviter un problème à cause d'une réaction du à l'env.
Personne n'est indispensable et l'on ne passe pas sa vie sur le même projet, il est important de penser au autres
Après ce n'est que m'a vision de la chose.
Un code est bon s'il est commenté, mais un mauvais code même commenté reste mauvais !
La différence entre amateurs et professionnels
C'est Master-NiKo (voir plus haut), qui a raison.
Apparemment le seul véritable professionnel.
La seule exigence d'un code est sa maintenabilité.
La maintenabilité peut être testée très facilement : on vire tous les développeurs d'une application, et on les remplace du jour au lendemain par des nouveaux dev (dans la vraie vie, ce genre de situation arrive)
Et ensuite vous regardez combien de temps la nouvelle équipe met pour comprendre et maitriser l'application.
Et là, suivant que l'application est bien documentée ou non, - et les commentaires sont une partie importante de l'application - car les docs "extérieures" sont rarement à jour, le temps de prise en main peut aller de 1 à 5.
Le nom des variables, des fonctions, le découpage du code est bien sûr important
Mais il faut mettre des commentaires ou vous expliquez ce que vous faites, aussi bien fonctionnellement que techniquement. vous ferez gagner du temps précieux à ceux qui vous succéderons (ou même à vous si vous relisez votre vieux code)
Si vous ne le faites pas, vous êtes un développeur amateur, qui ne pense qu'à son petit plaisir, sa petite bière après le travail, et qui se fout complètement qu'un jour un autre dev arrivant sur l'application n'y comprenne rien (alors que le dév amateur, lui, sera déjà dans une autre boite, ou il continuera à sévir).
Une application où il y a peu de commentaires n'est pas une application maintenable - et le choix correct de variables et de fonctions, c'est à peine 20% du travail.
Danfas
je ne met quasiment aucun commentaire... mes lignes de code sont de veritables romans... le nom des composants, variables et autres fonctions sont de veritables post-it... meme un vieux codes de plusieurs mois je replonge dedans comme si je l'avais pondu la veille. Alors bien sur les flemmards de l'ecriture trouverons mes libellés très long et inutiles... mais c'est rudement efficace. Et l'efficacité est un plus en informatique.
FN_transforme_Heures_en_Secondes() et cet exemple est plutot minimaliste.
je signale que je bosse seul... et donc cela me suffit... mais j'ai déjà fait l'experience d'un tiers travaillant sur mon code. Prise en main quasiment immédiate (tout relatif bien entendu) pas eu besoin d'explication.
Si c'est ce que tu fais de plus court, je n'ose pas imaginer ce que ça donne sur des trucs complexes...FN_transforme_Heures_en_Secondes() et cet exemple est plutot minimaliste.
Il faut que le code soit clair (et ça prend en compte les noms de variables / methodes simples ET explicites) et commenté (pensez a ceux qui prendront le code apres vous), et documenté.
En longueur ca ne prend jamais plus du double de l'exemple....et je préfère écrire des bouts de code très court (fonctions , procédures etc) qui se comprennent en quelques secondes... et mon code subit une mise en page assez rigoureuse... je ne comprends pas pourquoi nommer une variable avec un nom esoterique ou compressé et mettre un long commentaire pour expliquer son utilisté
Parce que devoir faire des scrolls latéraux pour lire du code, c'est pas terrible ? J'ai jamais parlé de var & fct aux noms ésotériques à propos, mais de noms clairs et simples (par opposition à l'écriture d'un roman en nommage d'une fonction...)En longueur ca ne prend jamais plus du double de l'exemple....
pour les noms esoteriques je ne faisais pas reference à ton messagemais à des bouts de code que j'ai rencontré ou sans commentaire, il est impossible de savoir de quoi il retourne... meme si tu ne sais pas a quoi sert mon programme à la lecture du code tu devines l'objectif... et ca le tiers qui a travaillé sur une de mes applications a prouvé d'une certaine manière l'efficacité de cette voie.
Pour les scrolls lateraux je n 'en fais jamais... la mise en page est essentielle?
mais au final chacun fait bien comme il veut si ca lui fait plaisir...
mouais...je ne suis pas fan, et j'évite le français dans le code car l'absence d'accent rend les choses parfois douteuses et les termes français sont généralement plus long que l'équivalent anglais.je ne met quasiment aucun commentaire... mes lignes de code sont de veritables romans... le nom des composants, variables et autres fonctions sont de veritables post-it... meme un vieux codes de plusieurs mois je replonge dedans comme si je l'avais pondu la veille. Alors bien sur les flemmards de l'ecriture trouverons mes libellés très long et inutiles... mais c'est rudement efficace. Et l'efficacité est un plus en informatique.
FN_transforme_Heures_en_Secondes() et cet exemple est plutot minimaliste.
je signale que je bosse seul... et donc cela me suffit... mais j'ai déjà fait l'experience d'un tiers travaillant sur mon code. Prise en main quasiment immédiate (tout relatif bien entendu) pas eu besoin d'explication.
Hour2Sec() me suffira largement
il faut aussi, je pense, faire une distinction entre code compilé et code interprété...si les commentaires et la longueurs des identifiants a peu d'impact sur un code compilé, ce n'est pas le cas pour un script.
Bonne remarque en effet, en interprété il y a un véritable intérêt à compresser la formulation.
Bonjour, pour moi, les commentaires doivent permettre de faire rapidement le lien entre la(les)SFD, les SFT(si elles existent) et le code. je pense que c'est le plus important pour la maintenance : savoir rapidement où se positionner pour faire une évol et comprendre l'architecture technico-fonctionnelle. mettre un commentaire avec la date et une référence à un autre document qui explique l'évol réalisée, les impacts, etc.. n'est pas mal en soi, sauf s'il y a eu trop de modifications un peu partout, car alors on rentrerait dans un autre type de casse-tête .. En résumé, pour moi les commentaires sont souvent nécessaires, mais c'est presque un métier que de les écrire ..
Le code auto-documenté ?!
Ok sur le principe. Dans la réalité c'est juste pas possible.
Chaque personne à une compréhension des mots d'une langue qui lui est propre. Du à son histoire. Chaque développeur pourra ainsi utiliser différent mot pour définir une méthode qui effectue le même traitement.
De plus, la maintenance et l'ajout de fonctionnalité est simplifié lorsque des phrase explique ce la méthode, fonction ou classe effectue. Surtout dans les grandes équipes ou comme certain le mentionne les niveaux sont pas tous identique.
Expérience personnel:
J'ai lu du code "auto-documenté" d'un développeur mathématicien. Et je peut vous dire que c'est une galère. Je ne suis pas un expert du C++ mais je suis pas mauvais. Quelque explication en commentaire c'est pas de trop. Surtout quand on utilise des algorithmes spécifiques à un métier.
comme en terre ?
Bon, je ne suis pas un spécialiste d'un langage ou d'un autre, en revanche, pour mes applis ou pour mes clients, lorsqu'il s'agit de développer du calcul scientifique, un minimum de commentaire s'impose.
Essayer de ne pas commenter les techniques de calculs matriciels, les optimisation par recherche de points de cols, vous m'en direz quelques nouvelles, surtout s'il faut revenir dessus quelques mois après réalisation.
Et j'parle pas des calculs différentiels de tous ordres!....parmi d'autres!
J'entends par là que le programmeur n'est pas toujours le chercheur, et son langage doit permettre une maintenance rapide et efficace.
Ouala...it's my advice !
Pour ma part, je suis totalement d'accord avec ce qui est dit dans cette article; le code devrait être assez claire pour dire ce qu'il fait dans la plupart des cas. Cependant, pour certains cas, c'est totalement nécessaire d'avoir des commentaires mais bien sûr, pour expliquer ce que le code ne peut pas dire.
Par exemple, si vous avec l'instruction suivant:
x = y * 26;
26 est un magic number. Il ne faut pas mettre un commentaire pour le 26, il faut faire une constante qui va dire ce qu'est la valeur 26. Ensuite, il se peut qu'un commentaire soit nécessaire pourquoi c'est 26. Ainsi, 26 peut devenir MAX_COLUMN et le commentaire sera 'Le client a décidé qu'il n'y aurait jamais un traitement de fichier Excel de plus de 26 colonnes.'
Il faut aussi considérer les commentaires xml dans mon cas où je programmes en .Net. Dans ce cas, pour un API publique, les commentaires peuvent s'avérer obligatoire pour permettre aux programmeurs qui vont utiliser votre API de savoir ce que fait chaque méthode de façon plus explicite. Là, est-ce qu'il faut documenter toute les méthodes, propriétés et classes avec ces commentaires. Ça va dépendre de la politique de votre compagnie.
Disons adieu aux méthodes de 100 lignes avec des bloques de code séparés par des commentaires.
Regardez bien une ligne commentée et posez-vous les questions :
- Est-ce que ça va m'aider dans 3 mois ?
- Est-ce juste (durablement) ?
- Est-ce redondant ?
Au moindre doute, on dégage le commentaire et on renomme les identificateurs.
Commenter un bloc de code au sein d'une méthode/fonction/procédure c'est reconnaître qu'il fallait en faire une fonction, alors découpez le code, faites en une fonction bien nommée et le code appelant deviendra lisible. La fonction est petite, la comprendre est immédiat. En C, utiliser l'inlining au besoin (pas d'impact de perf).
Commenter une méthode (au dessus) en explicitant l'algorithme utilisé, OUI, surtout si dans les commentaires on trouve pourquoi on n'a PAS fait comme ci ou comme ça.
Mais commenter `for( i = 0; i < count; ++i ) // pour balayer le tableau`, ça NON !
Les commentaires servent souvent à donner bonne conscience au cochon qui pond un code approximatif. Le commentaire est juste pendant un jour ou deux puis le code est mis au point et le commentaire ignoré devient faux.
J'aime mieux un code brut sans commentaire qu'un code lardé de commentaires dans un anglais de foire.
Répondre avec citation
Partager