Discussion :

[chaplin]

Sérieusement, ce qui peut être fautif dans le principe général : "aucune méthode de plus de N lignes", ce ne sont pas les cycles qu'on va perdre mais le fait que 70 lignes de code, s'exécutant de manière séquentielle, dans une seule fonction, sont nettement plus faciles à lire, comprendre, et débuguer que 7 méthodes "uniques mais surement réutilisables un jour, enfin peut être" de 10 lignes, éparpillées dans trois modules distincts, avec des noms qui ne sont pas forcément si évocateurs pris hors contexte.

Et si on applique un peu trop servilement ces principes de découplage (comme avec une application trop naive du principe de responsabilité unique), on se retrouve, dès que le programme devient un peu gros, un peu ancien, avec des verrues, avec ces abominables hiérarchies de classes qui donnent l'impression d'avoir été pensées par un bègue sous acide...

J'ai bien rigolé sur ce message. Je vois un intérêt, c'est la décomposition en fonctionnalité sans forcément rentrer dans le délire une classe une responsabilité. La contrepartie, c'est de faire du mode débug en mode pas à pas pour comprendre ce qu'il se passe. Au final, je suis toujours admiratif de voir des codes sources découpés avec des fonctions de quelques lignes.
Dans cette démarche, les commentaires peuvent être à l'extérieur de la fonction, avec une description des arguments en entré et sortie de la fonction. On a le meilleur compromis pour avoir du commentaire et le minimum syndical dans le code de la fonction.

[raubarede]

il est preferable de commenter les blogs,
quitte a bloguer le code

[BenoitM]

Ca c'est un bon exemple qu'un code pourri a besoin de commentaires pour être compris. Et pas qu'un code propre n'a pas besoin de commentaires

Et combien de projet as-tu vu qui a du code propre et combien avec du code pourri?
Et dans tout les projets que tu as du faire n'as tu jamais du refaire du code pourri?
Parce que quand tu dois faire une migration de code tu n'as toujours pas le loisir d'analyser le code.

[DevTroglodyte]

Ca c'est un bon exemple qu'un code pourri a besoin de commentaires pour être compris. Et pas qu'un code propre n'a pas besoin de commentaires

Si c'est plus complexe que "System.out.println("Helloworld");", il FAUT du commentaire. Par une pleine tartine, mais zut quoi, y'a des gens qui vont maintenir le code derriere. Et c'est pas parce que tu estimes ton code propre que lui va penser pareil.

[guillaume07]

Si c'est plus complexe que "System.out.println("Helloworld");", il FAUT du commentaire. Par une pleine tartine, mais zut quoi, y'a des gens qui vont maintenir le code derriere. Et c'est pas parce que tu estimes ton code propre que lui va penser pareil.

Un choix de nommage explicite des méthodes et variables doivent suffir dans la majorité des cas. Les commentaires doivent être limités pour lever les ambigiutés (qui doivent être rare).

[GPPro]

[HS]
Je suis sûr qu'on peut faire une typologie des développeurs et leurs commentaires en fonction de leur implication passée dans de la maintenance...
[/HS]

Peut-être pas si HS que ça en fait

[iMaTh]

Très souvent on ne travaille pas seul. Donc commenter c'est aider les collègues a comprendre.

La vraie intelligence dans la communication ce n'est pas de dire les autres doivent s'adapter a soit même, mais de faire le maximum pour ce que l'on tente de transmettre soit compris.

Et quand je vois ce genre de citation "Les commentaires c'est inutile", ça met vraiment le doigt sur un gros défaut de l'informaticien : la communication.

Il y a pas que la technique dans la vie !

[DevTroglodyte]

Un choix de nommage explicite des méthodes et variables doivent suffir dans la majorité des cas. Les commentaires doivent être limités pour lever les ambigiutés (qui doivent être rare).

C'est la théorie, ça. Dans la pratique on se retrouve avec un code rarement clair (sauf pour celui qui l'a écrit, et encore...).

[chaplin]

J'approuve les trois derniers post pour leur clairvoyance. Dans le contexte d'une tierce maintenance applicative, c'est franchement pénible de lire du code sans aucun commentaire. A part des frameworks, qui sont le fruit d'oeuvres collective et donc documenter par ailleurs, dans un domaine métier au sens MOA, parfois on lit du code comme des séquences d'ADN, avec des bugs!, des codes mis en commentaire et aussi des codes que seuls les auteurs comprennent.

S'il est question de communication et le terme est fondé, le commentaire est un complément d'information et non une source de pollution si l'on exclu ceux qui ne prennent pas la peine de mettre à jour les commentaires lorsqu'ils modifient le code source.

[Darkzinus]

Je plussoie allégrement les derniers posts, un code sans commentaires (ou mauvais) niveau maintenance c'est difficilement gérable et surtout beaucoup plus long ! Faire de la TMA est un bon moyen pour se rendre compte de l'intérêt des commentaires.

[bottus]

Je pense que l'interet des commentaires se fait sentir lorsque l'on code de façon impérative.
Lorsque l'on code en c++, le simple fait d'être dans une classe et pas dans une autre nous donne deja une vision bien précise du "sur quoi ce code va t'il avoir de l'impact". Ensuite avec des méthodes et attributs bien nommés, on s'en sort très bien pour peu que ce soit propre.
Je pense par contre que l'utilité des commentaires est présente avec des langages comme du C qui nécessite selon moi de l'explication, au moins pour faciliter son évolutivité.

[Luckyluke34]

sans commentaires, s'il faut lire 10 000 lignes de codes pour comprendre que l'affichage doit se faire impérativement dans le thread principal sinon ça plante, que ce soit découpé ou non en petites fonctions, il reste toujours (presque) autant de lignes à lire. Or cela aurait pu être évité par un simple commentaire d'une ligne.

Ca fait partie des cas techniques où je disais que des commentaires sont nécessaires. Je crois qu'on est tous d'accord là-dessus.

le fait que 70 lignes de code, s'exécutant de manière séquentielle, dans une seule fonction, sont nettement plus faciles à lire, comprendre, et débuguer que 7 méthodes "uniques mais surement réutilisables un jour, enfin peut être" de 10 lignes, éparpillées dans trois modules distincts

Plus faciles à débugger à la rigueur, plus faciles à lire et comprendre... on ne doit pas vivre dans le même monde. Quand il faut remonter 70 lignes plus haut pour voir à quelle valeur une variable a été initialisée, s'y retrouver dans 4 niveaux de if imbriqués, bref quand il faut que notre cerveau jongle avec des dizaines de symboles plutôt que quelques-uns dans une méthode courte et focalisée, j'ai du mal à voir où est le gain de lisibilité. J'ai toujours considéré comme évident que plusieurs petits problèmes bien découpés étaient plus facilement gérables qu'un gros touffu, mais c'est intéressant de voir que ce n'est pas l'avis de tout le monde.

Si c'est plus complexe que "System.out.println("Helloworld");", il FAUT du commentaire. Par une pleine tartine, mais zut quoi, y'a des gens qui vont maintenir le code derriere. Et c'est pas parce que tu estimes ton code propre que lui va penser pareil.

J'estime mon code propre quand, lorsque c'est possible, j'ai mis dans des noms de méthodes, de variables, de classes exactement ce que j'aurais pu mettre dans un commentaire. Je ne vois pas où est la différence entre les deux dans l'expressivité et la lisibilité du code, c'est la même chose.

[yoyo88]

Ne pas commenter rend le code difficilement compréhensible, mais trop commenter n'es pas bien non plus.
Mais c'est difficile de trouver un juste milieu.

Prenons un simple calcul de TVA.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
public decimal fonctioncalcultva(decimal arg1,decimal arg2)
        {
            return arg1* arg2;
        }

Ici le code n'es pas commenter, le nom de la fonction ne respecte aucune règle, bref rien n'es claire.



Voila le même code mais trop commenter.

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
/// <summary>
        /// Calcul du taux de TVA
        /// </summary>
        /// <param name="pValeurHt">valeur Hors taxe</param>
        /// <param name="pTaux">taux de tva</param>
        /// <returns>retourne la valeur calculer</returns>
        public decimal CalculTVA(decimal pValeurHt,decimal pTaux)
        {
            // Initilisation des variables
            decimal lValeurCalculer;
            // calcule du taux
            lValeurCalculer = pValeurHt * pTaux;
            //on retourne la valeur
            return lValeurCalculer;
        }

Ici on a respecté les normes mais on a voulu trop en faire et finalement on passe a coté de l'essentielle

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
/// <summary>
        /// Calcul du taux de TVA
        /// </summary>
        /// <param name="pValeurHt">valeur Hors taxe</param>
        /// <param name="pTaux">taux de tva</param>
        /// <returns>valeur Hors taxe * le taux de tva</returns>
        public decimal CalculTVA(decimal pValeurHt,decimal pTaux)
        {
            return  pValeurHt * pTaux;
        }

Pour moi pas besoin de plus, le code et suffisamment clair pour être compris du premier coup.
Le nom de la fonction, et les noms des arguments semble être suffisamment explicite.
De plus le code en entête viens aider à comprendre la fonction sans a avoir a fouiller dans la fonction pour comprendre le code.

[Paul TOTH]

Je pense que l'interet des commentaires se fait sentir lorsque l'on code de façon impérative.
Lorsque l'on code en c++, le simple fait d'être dans une classe et pas dans une autre nous donne deja une vision bien précise du "sur quoi ce code va t'il avoir de l'impact". Ensuite avec des méthodes et attributs bien nommés, on s'en sort très bien pour peu que ce soit propre.
Je pense par contre que l'utilité des commentaires est présente avec des langages comme du C qui nécessite selon moi de l'explication, au moins pour faciliter son évolutivité.

je pense très exactement le contraire.

dans un code C procédural il est relativement facile de savoir ce qu'on fait, alors qu'avec une arborescence objet C++ avec des classes virtuelles, des generics et cie, on a tout un tas de code très abstrait dont on ne sait à priori pas à quoi il sert, comment il est dérivé et/ou de quoi on dérive. On n'a pas de vision claire des événements de leur déclencheurs ou de l'ordre de leur déclenchement si toutefois il est défini.

[guillaume07]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
/// <summary>
        /// Calcul du taux de TVA
        /// </summary>
        /// <param name="pValeurHt">valeur Hors taxe</param>
        /// <param name="pTaux">taux de tva</param>
        /// <returns>valeur Hors taxe * le taux de tva</returns>
        public decimal CalculTVA(decimal pValeurHt,decimal pTaux)
        {
            return  pValeurHt * pTaux;
        }

Pour moi ici le commentaire n'apporte rien de plus si ça n'est de la pollution visuel, je préfère :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
        public decimal CalculTVA(decimal valeurHorsTaxe,decimal tauxTVA)
        {
            return  valeurHorsTaxe* tauxTVA;
        }

le nommage doit être explicite et ne pas contenir d'abréviation inutile

[sofien]

Il faut pouvoir assurer la relève par d'autres développeurs chose qui sera impossible sans que le code soit bien commenté...

Il faut aussi pouvoir reprendre le code rapidement...

Quand je dis commentaire, j'entends par ca des commentaires bien rédigés et surtout qui ne reprennent pas le nom de la cible des commentaires...

Le commentaire assure une meilleur lecture du code : c'est un guide en quelques sortes.

[yoyo88]

Pour moi ici le commentaire n'apporte rien de plus si ça n'est de la pollution visuel, je préfère :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
        public decimal CalculTVA(decimal valeurHorsTaxe,decimal tauxTVA)
        {
            return  valeurHorsTaxe* tauxTVA;
        }

le nommage doit être explicite et ne pas contenir d'abréviation inutile

alors oui et non, le code en entete bien que sans doute trop detailler et un element super important, pour la documentation deja. (meme sur un fonction simple c'est important) et de plus sur certaint IDE le commentaire en entete et afficher en annotation.

bon j'avoue la fonction etait un peu simpliste.

cependant cela parait clair car j'utilise le terme TVA que tous le monde comprend. j'aurrai utilise le terme anglais VAT pas sur que ça aurrai été si simple a comprendre, pourtant le code n'aurrai pas changer d'un poil.

[Invité]

J'ai toujours considéré comme évident que plusieurs petits problèmes bien découpés étaient plus facilement gérables qu'un gros touffu, mais c'est intéressant de voir que ce n'est pas l'avis de tout le monde.

On ne peut être que d'accord...

Maintenant, si le problème est simple, et que sa solution est bien découpée en un nombre pas trop important de petits morceaux explicites et faciles à comprendre, le code sera facile à comprendre et maintenir, que tu l'aies découpé en petites tranches fines, ou gardé en gros paquets séparés par des commentaires (et des initialisations locales de paramètres, et pas de if imbriqués... ce n'est pas parce qu'on code de grosses fonctions qu'on doit forcément coder illisible, ou idiot). Bref, c'est le pays joyeux des codeurs heureux, des devs gentils, c'est le paradis...

Si maintenant, le problème, ou plutôt sa solution, est compliqué, avec toutes sortes de cas particuliers tordus, qui interréagissent, et des effets de bords - si on est dans la vraie vie, quoi - on fait comment?

Ma sensation, c'est que le découpage en petits bouts ne rendra pas le code plus facile à comprendre. On échange un gros machin difficile, par une collection de petits machins simples, dont on ne comprend plus l'interaction (parce que si c'était facile, on serait dans le cas où le problème ne se pose pas). Et si tous ces éléments sont dispersés dans une collection de modules, et on tout un tas de propriétés que le développeur d'origine a ajouté "des fois que", ça devient vite très compliqué.

Avec ce code délocalisé, il est également beaucoup plus facile de tout casser en ne voyant pas un effet de bord (oui je sais, quand les problèmes sont simples, et bien découpés, cela n'existe pas... mais dans le monde réel...)

Une fois de plus, la caricature de cela, ce sont les hiérarchies de classes démentes, avec plein de petites classes qui font des petites choses minuscules, toutes très faciles à comprendre, mais qui cachent l'organisation générale du traitement effectué.

Ce type d'organisation est séduisante: quand on commence à le lire, on a l'impression de tout comprendre, que tout est simple.... jusqu'au moment où on se demande "comment ca marche", ou "comment le faire évoluer"...

Personnellement, dans le cas d'un traitement compliqué, je préfère nettement avoir une grosse "fonction coeur", avec une documentation éventuellement assez compliquée, et marqué en gros au dessus : "attention code tordu" pour éviter les interventions intempestives, qu'une organisation décentralisée.

Francois

[DevTroglodyte]

Pour moi ici le commentaire n'apporte rien de plus si ça n'est de la pollution visuel, je préfère :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
        public decimal CalculTVA(decimal valeurHorsTaxe,decimal tauxTVA)
        {
            return  valeurHorsTaxe* tauxTVA;
        }

le nommage doit être explicite et ne pas contenir d'abréviation inutile

Rien qu'à cause du mot clé "public" pour moi la doc d'en-tête (javadoc & assimilés) est nécessaire, que les noms de méthode et de variable soient explicites ou pas (d'ailleurs, explicite, c'est subjectif). Apres l'exemple est trop simple pour se prêter à des commentaires internes.

[SeBoun]

Les commentaires sont les meilleurs amis pour une équipe de codeur. Je m'en sers surtout pour mettre en évidence les structures du code afin de procéder à une relecture beaucoup plus rapide.