Interdire tous commentaires n'a pas plus de sens et n'est pas plus intelligent que de vouloir tout commenter.
Le meilleur commentaire, c'est bien sur le code lui-même, à condition qu'il soit bien écrit, que les noms de variables soient correctement choisies, que tout le monde comprenne ce choix et s'y tienne.
Tout simplement parce que le code sera finalement le seul commentaire toujours à jour.
Quoi de plus chiant que de mettre à jour le commentaire d'un code qu'on vient de mettre à jour ?
Pour ma part, je me contente de
- le header de la fonction en doxygen
- quelques commentaires au milieu, commentaires purement fonctionnels en général
Tout à fait, une interdiction pure et simple des commentaires me parait totalement absurde. Par contre encourager à un code clair et déconseiller les commentaires c'est différent, on laisse le choix au programmeur de faire ce qui est pertinent selon le contexte, c'est juste une "politique" à suivre. Mais tu n'as pas parlé d'interdiction formelle au début du sujet.
ne pas oublier qu'avec le temps on code différemment...mieux dans le meilleur des cas et quand on reprend son propre code 10 ans plus tard, il arrive qu'on trouve des horreurs ou des choses assez tordues dont la logique ne saute pas aux yeux. C'est d'autant plus vrai que 10 ans plus tard, toute la subtilité de la problématique n'est plus en tête (que ce soit le protocole utilisé, la structure de la bdd, le format de fichier etc...).
Je partage cet avis, comme plein de gens, mais je n'y adhère pas totalement. Les exemples montrés étaient caricaturaux, bien que j'ai encore tendance à écrire ce genre de commentaires. Sur le coup, ça peut paraitre bête mais c'est tellement plus simple à relire quelques mois ou années plus tard. Comme le dit très justement Paul Toth :
De plus, cela sous-entend qu'un code est toujours techniquement compréhensible, avec des méthodes et des variables aux noms tellement beaux et adaptés que les commentaires copient ces noms de variables et de méthodes.ne pas oublier qu'avec le temps on code différemment...mieux dans le meilleur des cas et quand on reprend son propre code 10 ans plus tard, il arrive qu'on trouve des horreurs ou des choses assez tordues dont la logique ne saute pas aux yeux. C'est d'autant plus vrai que 10 ans plus tard, toute la subtilité de la problématique n'est plus en tête (que ce soit le protocole utilisé, la structure de la bdd, le format de fichier etc...).
Mais des fois, commentez techniquement le code quand il y a des ruses de sioux ou des codes ésotériques tels que :
Les adeptes du K&R apprécieront le style ^^
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5
6
7
8
9 void *malloc(int s) { void *p ; s += sizeof(int) ; s = (s & 0xF) ? (s & ~0xF)+ 0x10 : s ; p = (s > 512) ? big_Malloc(s) : small_Malloc(s) ; *((int*)p)++ = s ; return p ; }
tient un autre cas ou le commentaire est bienvenu.
Je viens de tomber sur un bug IE9 totalement hallucinant...et comme je ne suis pas le premier j'ai trouvé une page qui montre le bug est le corrige.
je vais donc une fois de plus ajouter un commentaire du type <!-- corrige un bug IE - NE PAS SUPPRIMER -->
Les commentaire en début de méthode pour moi sont indispensables, ça permet la description de la méthode, et des paramètres. Après dans la méthode, tous dépendant de la complexité de celle ci, mais il faut rester dans la limite du raisonnable et ne pas avoir plus de ligne de commentaire que de ligne de code!
Tout est une question de contexte surtout. Plutot que de me demander ça je me demande plutot:
Est ce que le code va durer? va être repris? évoluer?
Combien de personne vont devoir s'en servir?
Etc...
Et en fonction de ça je commente les entetes, l'intérieur ou une doc pour expliquer l'archi général.
Pour ma part, je pense que la proportion de commentaires est liée au langage mais aussi au contexte.
On ne peut pas comparer les conditions de maintenabilité de la même façon en gestion d'incident planifiée et en stress avec une obligation de résultat.
Dans ce deuxième cas avoir des commentaires inclus dans le programme aide certainement à répondre plus rapidement et plus surement.
Sur des langages non objets j'applique un ratio de 20% de commentaires en moyenne et je ne suis pas sur d'être dans le cadre de la norme ISO. Mais je suis plutôt à 5% sur du C# .
en C# par odre d'importance
1) Commenter les fonctions
2) Utiliser les regions pour découper les classes (attributs, propriété,methodes, implémentation d'interface)
3) Utiliser les regions pour regrouper plusieurs fonctions
4) Expliquer le pourquoi on fait certainnes actions en cas de nécessiter
5) Utilisation des régions pour découper certaines fonctions trop longue si on a pas eu le courage de les découper en plus petites
Personnellement mes codes sont très verbeux, c'est tip top pour s'y retrouver, par contre le code en prod ne contiens pas un seul commentaire.
Je minimise les sources au maximum ce qui rend le code illisible mais plus réactif.
Je si je comprends bien au moment de mettre en prod tu fait un revu de ton code en supprimant tous les commentaires. Je trouve ca un peu bizarre car si on raisonne sur la taille du projet je ne pense pas que les commentaires augmentent plus 500 Mo de la taille de ton projet. Pour la compilation et l'exécution, les commentaires ne sont pas pris en charge c'est pourquoi je trouve bizarre de supprimer les commentaire pour la mis en prod
Je rajoute ma petite expérience.
Boite de JV, solution maison (C++). Au début je mettais des petits bout de commentaire en tête de blocs pour expliciter ce que je faisais (//Check the main character's inventory.." -- Bloc d'une 20aine de ligne)
On m'a précisé que c'était inutile. Sauf cas particulier (astuce, dépendance qui impliques des choses "bizarres"..), le code doit être suffisamment clair pour être compréhensible: "Le code est sa propre documentation".
Si le code nécessite des commentaires toutes les 2 lignes, c'est qu'il n'est pas assez clair, que la fonction fait trop de chose, que les variables n'ont pas des noms assez explicites etc..
La question ne se pose pas, les commentaires sont necessaires.
Et pourtant...
Qu'est-ce qui va plus vite ? Lire une phrase explicite, ou bien un code de 15 lignes explicite ?
Ex :
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16 /* Did the read went fine ? */ if (return_code == MY_RETURN_KO) { bla bla bla bla appel de fonction de remplacement if (appel a merde la aussi) { bla bla erreur bla bla } fin du bla bla }
Par ailleurs, dans les editeurs de code qui permettent de replier des parties de code, tu vois le commentaire, le if, et c'est tout. Tu n'as donc pas a deplier le code pour savoir ce qui est fait dedans.
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.
Partager