Discussion :

[koala01]

Génial les outils de versionning... à l'heure actuelle,

=> mais les applis à maintenir ne sont pas toutes récentes

Qu'est ce qui t'empêche, si un projet n'est pas sous contrôle de version, de le mettre en partant de l'état actuel dans lequel il se trouve?

=> l'industrie logiciel reste encore à s'imposer

Ah ben, ca, c'est pas nouveau

=> ce n'est pas toujours le développeur qui gère le versionning, surtout en grosse équipe

Non, mais plus l'équipe est importante, plus il me semble nécessaire d'avoir un système de versioning... si ce dernier est géré par "un autre service", je m'en fous, du moment qu'il fonctionne

=> et quid dans 10 à 20 ans ?

Si dans dix ou quinze ans, il décident de changer le système de contrôle de version, cela ne me pose strictement aucun problème

A la limite, tant qu'ils veillent soit à garder les deux systèmes en parallèle un temps suffisant, soit à transférer l'historique, cela me convient parfaitement

Mais cela nous éloigne vraiment beaucoup du problème de base

Ce qui peut sembler inutile en Java ne l'est peut-être pas en Cobol, justement du fait des différences.
Ce n'est pas un commentaire inutile qui pose problème, c'est l'absence de commentaire.

non, c'est un commentaire non mis à jour qui pose problème.

La première source de compréhension du code devrait toujours être le code en lui-même!

C'est le seul moyen certain pour s'assurer que cette source reste en corrélation avec le code lui-même

La qualité c'est la bonne pratique,
la bonne pratique c'est de disposer du maximum d'information
l'information c'est d'abord le code commenté

la bonne pratique, c'est de disposer du maximum d'informations, je te l'accorde.

Mais la meilleure source d'information que tu puisse avoir, la seule dont tu puisses être certain qu'elle sera en parfaite adéquation avec le code, c'est le code lui-même.

Cela impose certes une certaine discipline, en terme de choix de noms essentiellement, mais c'est ca qui fera la qualité essentielle d'un "bon code"

Personne ne sait qui interviendra dans les arcanes de nos sources, quand il le fera, pourquoi il le fera et comment il les abordera.
Alors plus il aura d'informations moins il perdra de temps ( et moins il nous prendra pour un charlot )

A partir du moment où tu respecte la sémantique généralement attribuée aux différents opérateurs et où tu choisi des noms cohérents et compréhensibles pour tes fonctions et pour tes variables, en quoi voudrais tu qu'on te prenne pour un charlot?

Bien sur, si tu codes un opérateur '<' en lui donnant le sémantique de l'opérateur '==' ou de l'opérateur '>', là, tu as de fortes chances d'être pris pour un charlot

Oui la maintenance à un coût, et plus on perd du temps à comprendre le code plus c'est cher. Et on perd du temps souvent parce que l'on ne comprend pas ce que le développeur a voulu faire et qu'il ne l'a pas expliqué !

Parce que tu crois peut être que l'on ne perd pas de temps simplement parce que le code est commenté

L'homme est par défaut un fainéant, et le développeur ne fait pas exception.

S'il a la possibilité de choisir la loi du moindre effort, il la choisira.

Autrement dit, s'il doit choisir entre lire un commentaire et se baser sur le principe que le code auquel le commentaire se rattache fait effectivement ce que le commentaire prétend et relire le code, il choisira d'office de lire le commentaire.

Le problème est donc que si le commentaire n'est pas en parfaite adéquation avec le code, il "sautera" la partie correspondante du code en se disant "bah, si le commentaire le dit, faisons lui confiance".

Il va donc se perdre en conjonctures de toutes sortes sur d'autres parties, parfois très éloignées du point réel où le problème se pose.

Au final, un mauvais commentaire aura fait perdre beaucoup plus de temps que celui qu'un bon commentaire aurait pu faire gagner

Donc c'est bien juste un problème de budget ( de temps ), pas de technique ( même si c'est mal écrit, c'est maintenable ).

Les commentaires ne changent rien à cela.

Si tu n'a pas été en mesure de fournir un code compréhensible, pourquoi serais tu en mesure de fournir des commentaires qui permettent de comprendre ton code

Un code mal écrit est mal écrit et difficile à maintenir, fut il truffé de commentaires, point barre.

Un code bien écrit, qui respecte quelques principes de base comme le principe de la responsabilité unique n'a pas besoin de commentaires parce que la qualité du code en lui-même les rend inutiles et sera pourtant facilement maintenable

[Matthieu Vergne]

La qualité c'est la bonne pratique,
la bonne pratique c'est de disposer du maximum d'information
l'information c'est d'abord le code commenté

Personne ne sait qui interviendra dans les arcanes de nos sources, quand il le fera, pourquoi il le fera et comment il les abordera.
Alors plus il aura d'informations moins il perdra de temps ( et moins il nous prendra pour un charlot )

La surinformation est toute aussi problématique. J'utilise un design pattern, disons une factory, classique et je le commente comme un débutant. Le programmeur qui vient derrière voit tout de suite la factory, et mes commentaires quand il les lit il se demande si j'ai pas essayé de faire autre chose (builder ?). Et là il perd du temps car il essaye de trouver s'il a pas zappé un truc quand il a identifié la factory... perte de temps puisque c'en était bien une.

Avoir plus d'information c'est comme tout : s'il y en a trop, on est perdu, et si la qualité n'est pas au rendez-vous ça fait plus de mal que de bien. Le code c'est pareil, c'est juste une autre façon de le dire. Et comme le code est obligatoire et le commentaire non, on a vite vu où la qualité doit primer, donc autant mettre ses efforts dessus.

[Aqualys]

Sans vouloir être offensant, c'est le monde des bisounours :

- les applis suivraient les évolutions des outils ( compilateur, gestionnaire de version, framework, ... ), alors qu'en réalité il faut pleurer ( et faire moult démonstrations ) pour que les applis suivent seulement les upgrade d'OS, de SGBD ou de Progiciels.
- les gentils développeurs seraient tellement pro, leurs codes bien écrits, livrés dans les temps ( une recette serait-elle nécessaire ? "tester c'est douter" ), alors que il n'y a jamais assez de temps, que le turn-over multiplie la difficulté du suivi ( 1 jeune sur 2 préfèrerait réécrire que chercher à comprendre ), que la conception n'est toujours pas finalisée...

Je fais de la recette, de la maintenance et du débogage d'applications que je n'ai pas écrites, depuis + de 10 ans ( après 12 ans d'édition de progiciels ), et c'est ce que je vois tous les jours depuis mes débuts.

Oui, mettre à jour les commentaires est important, c'est ce que j'ai appelé les évolutions.
Oui, trop d'information peut nuire, mais je n'ai jamais vu de code avec trop de commentaires ( avec des commentaires obsolètes ou inutiles ; oui )

Quand on regarde du code, on le lit, les commentaires sont un complément ( c'est comme lire un livre, les notes de bas de page sont un complément, parfois pas toujours utile ).

Du code bien écrit, je ne sais pas ce que çà veut dire.
Si il tourne et fait ce qu'on lui demande, le décideur/payeur dira que c'est bien écrit
Si il est documenté, versionné, sauvegardé, le directeur de projet dira que c'est bien écrit
Si il est normalisé, commenté, optimisé, l'équipe de maintenance dira que c'est bien écrit
Le développeur qu'il l'a fait dira toujours que c'est bien écrit !

[Cogito.11]

Sans vouloir être offensant, c'est le monde des bisounours :

100% d'accord

Du code bien écrit, je ne sais pas ce que çà veut dire.
Si il tourne et fait ce qu'on lui demande, le décideur/payeur dira que c'est bien écrit
Si il est documenté, versionné, sauvegardé, le directeur de projet dira que c'est bien écrit
Si il est normalisé, commenté, optimisé, l'équipe de maintenance dira que c'est bien écrit
Le développeur qu'il l'a fait dira toujours que c'est bien écrit !

Full d'accord aussi

Un code bien ecrit , ca ne veut rien dire. C'est trop subjectif. Ca depend de qui le lis.

[Jérôme_C]

Un code bien ecrit , ca ne veut rien dire. C'est trop subjectif. Ca depend de qui le lis.

Donc en dernier recours il faudra demander au développeur s'il a bien écrit son code. S'il avoue qu'il a mal écrit, yaka rajouter des commentaires

[Cogito.11]

... S'il avoue qu'il a mal écrit ...

Ca existe des developpeurs comme ca ?

[Matthieu Vergne]

Oui bien sûr, mais faut savoir traduire le langage de programmeur. Généralement ils disent "ça marche pas et je sais pas pourquoi" ou "oui, j'y suis presque !" {^o^}.

[koala01]

Un code bien ecrit , ca ne veut rien dire. C'est trop subjectif. Ca depend de qui le lis.

Donc en dernier recours il faudra demander au développeur s'il a bien écrit son code. S'il avoue qu'il a mal écrit, yaka rajouter des commentaires

C'est peut etre subjectif, mais, il ne faut pas oublier que le premier qui devra poser les yeux sur le code c'est... le développeur (ou, du moins, l'équipe de développement / de maintenance).

C'est donc leur avis qui primera s'il s'agit de faire un "audit qualité" sur la manière dont le code est écrit (car on parle uniquement de la qualité d'écriture du code ici, et non des différentes visions que peuvent avoir le gens quant à l'efficacité ou la justesse du code )

Je serais presque d'avis que l'on peut déjà se dire que le nombre de commentaires rajoutés dans le code est à la limite un indice du fait qu'un code est mal écrit.

Que plus les commentaires sont nombreux, plus le code risque d'être mal écrit pour une raison bien simple : si le code est truffé de commentaire, il y a de fortes chances pour que celui qui l'a écrit s'est lui-même rendu compte qu'il était difficile à suivre et à comprendre

[Cogito.11]

... C'est donc leur avis qui primera s'il s'agit de faire un "audit qualité" sur la manière dont le code est écrit ...

Mouais, enfin j'ai jamais vu, non plus, un audit qualité dire qu'un code etait bien ecrit... c'est beaucoup moins vendeur.

Ce serait interessant de parler des audits ... qu'ils sont nombreux, ces messieurs qui critiquent sans avoir jamais tapé une ligne de code sous la contrainte d'un client ou d'un patron qui veut des résultats pour hier...

[koala01]

Mouais, enfin j'ai jamais vu, non plus, un audit qualité dire qu'un code etait bien ecrit... c'est beaucoup moins vendeur.

C'est bien pour cela que j'avais mis les termes entre guillemets

Ce que je voulais dire par là, je l'ai explicité dans la suite de ma réponse : les meilleurs juges de la qualité d'écriture (et j'insiste encore une fois sur ce seul terme ) d'un code, ce sont ceux qui doivent mettre les mains dans le cambouis : celui qui l'écrit et ceux qui le relisent / le corrigent / le modifient (biffer les mentions inutiles ).

Mais, très clairement, je fais partie de ceux pour qui un code doit être auto suffisant en terme de compréhension, ce qui fait, encore une fois, que je suis tout près de considérer que plus un code a besoin de commentaires, plus il est "mal écrit".

Si l'on choisit dés le départ un nom correct pour les variables et les fonctions, si on évite de créer des fonctions qui font la vaisselle, la lessive, le café et qui sortent en plus le chien, si l'on veille à garder une logique la plus simple possible, un code peut être considéré comme "bien écrit", même si on s'est trompé dans la logique (il est si facile de faire un test d'égalité lorsqu'on aurait du faire un test "plus petit que" pour déterminer s'il faut rentrer dans une boucle) et que le code ne fait donc pas forcément ce qu'il devrait.

J'estime, en tant que développeur, qu'un code doit d'abord être lisible, avant de faire ce qu'on attend de lui, et bien avant d'être optimisé, car il est beaucoup plus facile de corriger un code facile à lire qu'un code qui ne l'est pas.

Mais j'estimes que la très grosse majorité des commentaires -- en gros, tous ceux qui ne font pas partie du cartouche -- n'apportent strictement rien en terme de lecture du code et ne sont au final qu'un symptôme plaidant en faveur que le code est mal écrit

[Cogito.11]

...Mais, très clairement, je fais partie de ceux pour qui un code doit être auto suffisant en terme de compréhension, ce qui fait, encore une fois, que je suis tout près de considérer que plus un code a besoin de commentaires, plus il est "mal écrit".

je suis complètement d'accord.
Et n'utiliser les commentaires que pour les modifs tout au long de la vie de ce code.

[r0d]

Je suis d'accord sur le fait que la part de subjectivité dans cette question est importante.
Par exemple, pour certains développeurs (et j'en connais des comme ça), le code suivant sera nickel:

Code :

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

1
2
logic.RSLatch.r = true;
FSM()::SS( logic.RSL.s );

Pour d'autres (et j'en connais aussi), il faudra écrire:

Code :

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

1
2
object_that_contains_the_logic_of_the_application.getResetSetNORLatch().setReset( true );
MyFiniteStateMachinePersoImplémentéeSelonLeDesignPatternSingletonAvecUnOperateurDeFonction()::SetCurrentState( object_that_contains_the_logic_of_the_application.getResetSetNORLatch().getSet() );

[koala01]

je suis complètement d'accord.
Et n'utiliser les commentaires que pour les modifs tout au long de la vie de ce code.

Et encore!!!
S'ils se contentent de rappeler le numéro d'issue d'un bug, pourquoi pas...

S'il vont plus loin que cela, ils commenceront rapidement à m'inquiéter

Je suis d'accord sur le fait que la part de subjectivité dans cette question est importante.
Par exemple, pour certains développeurs (et j'en connais des comme ça), le code suivant sera nickel:

Code :

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

1
2
logic.RSLatch.r = true;
FSM()::SS( logic.RSL.s );

Pour d'autres (et j'en connais aussi), il faudra écrire:

Code :

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

1
2
object_that_contains_the_logic_of_the_application.getResetSetNORLatch().setReset( true );
MyFiniteStateMachinePersoImplémentéeSelonLeDesignPatternSingletonAvecUnOperateurDeFonction()::SetCurrentState( object_that_contains_the_logic_of_the_application.getResetSetNORLatch().getSet() );

Les deux codes présentent, à mon sens un problème:

Pour le premier : que sont FSM, SS RSLatch et RSL et que font ils

Le deuxième présente, déjà, un problème de nomenclature: les classes et les variables portent des noms beaucoup trop long qui pourraient sans problème être raccourcis (MyFiniteStateMachinePersoImplémentéeSelonLeDesignPatternSingletonAvecUnOperateurDeFonction pouvant être raccourci en MyFiniteStateMachine et object_that_contains_the_logic_of_the_application pouvant s'appeler simplement object), mais, surtout, le fait que le code mélange allègrement l'utilisation de l'underscore et celle qui consiste à placer les premières lettres de chaque mot en majuscule.

Sans même parler de la const correctness qui semble très loin d'être respectée lorsqu'on invoque une fonction getResetSetNORLatch pour appliquer une fonction getSet à ce qui a été renvoyé par cette fonction.

Je reconnais sans aucun problème que la subjectivité est importante quand on parle de "code bien écrit", mais il y a quand même assez facilement moyen de trouver un "juste milieu" entre le fait de n'utiliser que des initiales et celui d'exprimer en un phrase complète ce qu'on peut exprimer en trois mots

[AdmChiMay]

Il y a des commentaires qui sont superfl(o)us dans l'immédiat, car c'est évident. Mais 6 mois plus tard beaucoup moins.

Là, je pense à du code VBA-Excel, où selon la version de Office, le comportement n'est pas le même. Ou alors où une astuce se trouve seulement à partir de la 20è page de Google. Et je commence à penser d'un point de vue pratique que c'est la même chose avec les bibliothèques C/C++ voir autres.

Donc le commentaire :
- après 6 jours, s'il y est encore : "b----l le c-n mais c'est évident !" (même si le c-n c'est soit-même)
- après 6 mois, s'il n'y est pas : "mais c'est quoi ce b----l ?" (et là, le c-n, c'est bien soit-même).

[patxy]

Quand tu dois exécuter des calculs/requêtes qui demandent une optimisation des perfs, ce n'est pas toujours le code le plus lisible qui est le plus efficace.
Dans ce cas, les commentaires sont indispensables.

Parfois, quand on utilise des librairies développées par d'autres, on doit faire appel à des méthodes dans lesquelles on envoie des "true", "false", "null",...
Un commentaire pour en rappeler la raison permet aussi d'éviter de devoir faire des aller-retours incessants dans la doc.

[koala01]

Quand tu dois exécuter des calculs/requêtes qui demandent une optimisation des perfs, ce n'est pas toujours le code le plus lisible qui est le plus efficace.
Dans ce cas, les commentaires sont indispensables.

La lisibilité du code n'a rien à voir avec son efficacité.

Ta requête peut effectivement être (très) complexe, mais c'est à toi de veiller à ce que la manière dont elle sera générée reste lisible!

Après tout, toute requête n'est "jamais" qu'une concaténation de chaine de caractères, qu'est ce qui t'empêche de concaténer cette chaine en plusieurs étapes, en appelant des fonctions (correctement nommées !!) qui créent chacune une partie de la requête

Parfois, quand on utilise des librairies développées par d'autres, on doit faire appel à des méthodes dans lesquelles on envoie des "true", "false", "null",...
Un commentaire pour en rappeler la raison permet aussi d'éviter de devoir faire des aller-retours incessants dans la doc.

C'est pour cela que le cartouche est nécessaire à l'endroit où ta fonction est déclarée (car on part du principe que tu as toujours au minimum accès à la déclaration de ta fonction ).

Si le cartouche n'est pas disponible pour une raison ou une autre, c'est de toutes manières au niveau de la doc de la bibliothèque externe que tu apprendras la manière de l'utiliser, non au niveau du code qui l'utilise

Ces informations n'ont strictement rien à faire dans le code qui utilise la bibliothèque tierce : le try... catch, le if (truc.function()) doivent, encore une fois, se suffire à eux même.

[patxy]

La lisibilité du code n'a rien à voir avec son efficacité.

Ta requête peut effectivement être (très) complexe, mais c'est à toi de veiller à ce que la manière dont elle sera générée reste lisible!

Après tout, toute requête n'est "jamais" qu'une concaténation de chaine de caractères, qu'est ce qui t'empêche de concaténer cette chaine en plusieurs étapes, en appelant des fonctions (correctement nommées !!) qui créent chacune une partie de la requête
C'est pour cela que le cartouche est nécessaire à l'endroit où ta fonction est déclarée (car on part du principe que tu as toujours au minimum accès à la déclaration de ta fonction ).

Si le cartouche n'est pas disponible pour une raison ou une autre, c'est de toutes manières au niveau de la doc de la bibliothèque externe que tu apprendras la manière de l'utiliser, non au niveau du code qui l'utilise

Ces informations n'ont strictement rien à faire dans le code qui utilise la bibliothèque tierce : le try... catch, le if (truc.function()) doivent, encore une fois, se suffire à eux même.

Au pays des bisounours ton argumentation aurait peut-être du sens... Et encore...
On a compris que tu étais contre l'utilisation des commentaires. Pas besoin de troll tous ceux qui ne sont pas de ton avis. Avec autant de mauvaise foi que toi, je pourrais aisément démonter tous tes commentaires, mais ça ne ferait en rien avancer le schmilblick.

[Matthieu Vergne]

Je vois pas de troll dans son post. Certes il réaffirme son opinion, ce qui peut être lourd, mais ça n'a rien de la mauvaise foi. C'est un point de vue qui a ses arguments, au même titre que le tien.

[koala01]

Au pays des bisounours ton argumentation aurait peut-être du sens... Et encore...
On a compris que tu étais contre l'utilisation des commentaires. Pas besoin de troll tous ceux qui ne sont pas de ton avis. Avec autant de mauvaise foi que toi, je pourrais aisément démonter tous tes commentaires, mais ça ne ferait en rien avancer le schmilblick.

Contrairement à ce que tu crois, il ne faut trouver aucun troll ni aucune mauvaise fois dans mes écrits.

Je ne fais que défendre un point de vue que j'ai émis il y a déjà bien longtemps dans cette discussion qui est qu'un code "bien écrit" (du point de vue du développeur est, d'abord et avant tout), un code dans lequel

1. les différents noms sont correctement choisis, et respecte des règles de codage strictes (ne pas avoir une classe ma_classe_machin_chose et une autre MaClasseToutAutreChose dans le même projet )
2. chaque fonction ne fait qu'une chose mais veille à le faire correctement
3. la mise en forme est cohérente et permet de repérer le cas échéant les différentes étapes au premier coup d'oeil

Et qu'un tel code dispose de tout ce qui lui faut pour se suffire à lui-même.

Montres moi un seul code qui respecte ces deux conditions et qui nécessite encore des commentaires pour aider le lecteur à le comprendre, et je changerai d'avis

On parlait de requêtes complexe (c'est d'ailleurs ce qui a justifié l'intervention que je viens de citer), hé bien soit:

Prenons n'importe quelle requête complexe et essayons un tout petit peu de l'analyser:

Code :

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

1
2
3
SELECT <liste de tables et de champs, de différentes tables s'il échoit> 
WHERE <différentes conditions, avec peut etre des requêtes imbriquées> 
INHER JOIN <liste de jonctions à effectuer> ON <liste de champs à joindre>

Tu as deux solutions pour travailler :

La première consiste à créer ta requête de manière tout à fait statique (tous les paramètres que j'ai placé ici entre < et > sont remplacés dans la requête par les valeurs qui vont bien), ou peu s'en faut.

Tu vas te retrouver avec un grand nombre de chaines pour représenter tes différentes requête, toutes plus difficiles à lire les unes que les autres, et pire que tout, avec une grande probabilité pour que certaines requêtes ne diffèrent d'une autre que par l'ajout ou la suppression du nom d'un champs ou d'une condition.

Autrement dit, si une requête ne te donne pas le résultat espéré, tu est bon pour :

1. arriver à trouver exactement la requête qui fait défaut
2. arriver à trouver dans cette requête "kilométrique" LE paramètres qui fout ta requête en l'air

Autant chercher une aiguille dans une meule de foin

La deuxième solution consiste à créer tes requêtes de manière dynamique, autrement dit d'avoir une fonction qui se chargera de choisir les champs qui t'intéressent, une autre qui se chargera d'indiquer les conditions qui t'intéressent, une troisième qui prendra en charge la clause INHER JOIN, et une quatrième qui s'occupera de la clause ON.

Lorsque tu as besoin d'une requête spécifique, il n'y a strictement rien qui t'interdise de générer ta requête "par petits bouts", dans des fonctions (dont le nom est bien choisi) simples, faciles à comprendre, faciles à analyser, au besoin en dressant la liste de ce dont elles ont besoin pour travailler

"Tout ce qu'il te faut", c'est un ensemble de données qui soit en accord avec le type de réponse que tu attends.

Alors, bien sur, tu peux très bien avoir quelques requêtes simples, renvoyées "telles quelles" par la fonction ad-hoc (SELECT id from clients where id = <id du client recherché> , SELECT * from fournisseur where encours between 0 and <valeur maximale> , voire SELECT <liste de champs> from <liste de tables> where <liste de conditions> ) mais, le fait est que, en créant un petit nombre de fonctions correctement nommées et en leur passant les paramètres sous la forme de variables tout aussi correctement nommées toutes tes requêtes, y compris les plus complexes se limiteront à de la concaténation.

Il n'y a strictement rien qui t'empêcherait d'avoir une fonction

Code :

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

createSomeSpecificComplexRequest(listSearchedFild, listCondition, listInhejoin, listOnClause)

qui prendrait la forme de

Code :

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

1
2
3
4
createSomeSpecificComplexRequest(listSearchedFild, listCondition, listInhejoin, listOnClause){
    string query =createSearchedFields(listSearchedFild) + " " + createConditon(listCondition) + " " + createInherJoin(listInhejoin) + "  " + createOnClause(listOnClause);
    return SqlQuery(query);
}

et il n'y aurait strictement rien qui t'empêcherait d'utiliser la requête ainsi formée pour la rajouter dans la clause WHERE d'une autre requête, à ce que je sache

Pour autant que tu nommes correctement ta fonction (car createSomeSpecificComplexRequest mérite d'être autrement mieux nommé), tu n'auras strictement pas besoin de commentaire lorsque, dans une autre fonction, tu verras un truc du genre de

Code :

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

string query= createSearchedFields(listSearchedFild) + " " + createConditon(listCondition) + " OR (" createSomeSpecificComplexRequest(/*...*/).queryString() + " " + createInherJoin(listInhejoin) + "  " + createOnClause(listOnClause);

Encore une fois, le code, bien que complexe, se suffit strictement à lui-même car il ne plane aucun doute sur ce qui est fait par les différentes fonctions (ou du moins, sur ce qui est sensé être fait par ces différentes fonctions )

Contrairement à ce que l'on peut croire, le fait de mettre en place un (grand) nombre de fonctions (très) clairement spécialisées est très rarement une perte de temps, bien au contraire :

• Cela permet de garder des fonctions particulièrement simples, donc, facile à comprendre, faciles à débugger, faciles à utiliser.
• Cela permet, si l'on en a le temps, de les tester beaucoup plus facilement
• Cela permet une souplesse beaucoup plus grande parce que, à partir du moment où la fonction existe, il n'y a plus qu'à l'utiliser
• Cela évite un grand nombre d'erreurs dues à un copier / coller foireux ou malheureux qui rendrait le débuggage, la compréhension ou l'utilisation difficile ou hasardeuse.

Tout ce à quoi il faut être attentif, à partir du moment où l'on a de telles fonctions, c'est à veiller à leur donner des noms qui soient en relation avec leur utilité.

Si tu combine (un grand nombre de) fonctions clairement spécialisées avec des règles de nommage strictes et, tant qu'à faire, des règles de mise en forme cohérente, ton code sera d'office lisible et se suffira à lui-même.

PS : Merci Matthieu Vergne de ton intervention car il n'y a effectivement ni mauvaise foi ni troll dans mon intervention.

J'attends simplement de la part de ceux qui déterrent à chaque fois ce débat pour dire que les commentaires sont nécessaires qu'il me montrent un seul code respectant les quelques règles simples que je viens d'énumérer pour la énième fois a, malgré tout, encore besoin de commentaires

[Neckara]

Montres moi un seul code qui respecte ces deux conditions et qui nécessite encore des commentaires pour aider le lecteur à le comprendre, et je changerai d'avis

J'ai écrit il y a peu un code assez complexe pour retirer automatiquement les pierres inutiles à la fin d'une partie de Go.

L'algorithme est très facile pour un humain mais pour l'écrire dans un langage, j'ai été obligé de me casser la tête pendant des jours entiers pour trouver des équivalences.

Je pense donc qu'il est nécessaire d'expliquer dans les cartouches des fonctions l'algorithme "pas détaillé" pour expliquer pourquoi il fait ce qu'on voulait mais je pense aussi qu'il faille mettre dans le code quelques commentaires pour expliquer plus en détails quelques points d'algorithme rapidement.

Bien sûr mon code ne doit pas respecter correctement toutes tes règles donc je ne pourrais pas te le proposer en contre-exemple.

Après, il y a la théorie et la pratique. Une personne peut être sûre d'avoir respecté tous tes principes correctement mais un relecteur pourrait ne pas être de cet avis donc rajouter des commentaires à certaine ligne peut parfois aider (d'ailleurs qui peut affirmer n'écrire que du code respectant tous les bonnes pratiques de programmation?). J'ai par exemple écrit du code pour une entreprise qui sera sûrement repris par un stagiaire, ce dernier sera assez content d'avoir quelques commentaires.

Bien sûr tout est histoire de proportion, il ne faut pas en abuser non plus.

Enfin bref, je pense qu'on passe ici plus de temps à débattre sur pourquoi les commentaires sont inutiles qu'à les écrire