Discussion :

[deuz59]

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.

de rien, content que cette lecture ai pu t'aider à mieux comprendre les tenants et aboutissants de cette position

En effet, cela reste un recueil et des points de vues liées aux expériences de l'auteur et des personnes qu'il a pu interroger, à chacun de se forger sa propre opinion basée sur son expérience, mais en tant que débutants cela reste une bonne base pour pas partir sur de fausses bonnes questions et faire à peu près bien dès le début, pour des plus expérimentés, cela permet de confronter les points de vue et peut être mieux viser la cible inatteignable du code idéal pour tous

Ce que je rejette c'est d'indiquer comme règle d'or de la qualité de commenter, commenter et toujours commenter, cela fait s'écarter des vrais problématiques et du coup n'aide pas à l'amélioration du code
Mais je ne dis pas non plus "Fais du code propre et ne mets aucun commentaire", mais plutôt "efforce-toi à ne pas avoir recours aux commentaires" (autrement dit "concentre toi sur l'écriture de bon code"), dès lors qu'en tout dernier recours, la mort dans l'âme, tu écris ton commentaire qui aurait pu être éviter mais que tu as vraiment tout essayé avant et sais que ça pourra être (ou plutot sera) revu ultérieurement, alors là OK, l'amélioration du code est en bonne voix

C'est justement parcequ'il est utopique d'écrire naturellement et toujours un code le plus parfait possible (ne serais que pour une question de temps mis à notre disposition pour le faire) qu'une autre règle liée à la qualité est de "laisser la place un peu plus propre qu'on l'a trouvée" afin justement de maintenir/améliorer la qualité du code au fur et à mesure que "le projet s'expanse"...et comme rien n'est simple, il faut faire avec une règle qui se défend très bien car touche directement au résultat pour le client final (celui qui paie !) : "le moins on touche au code, le mieux on évite les régressions" ==> c'est pourquoi qu'une autre règle doit être appliquée : "Tester, tester, retester encore" (un jeu de tests unitaires complet et corrects doit être maintenu pour permettre un refactoring aux risques maîtrisé....et le petit plus comme cela à déjà été dit ici, les test unitaires restent une très bonne documentation du code en ce sens où ils permettent de savoir exactement ce que doit ou pas faire telle ou telle méthode)
==> la qualité est vraiment un tout !!

[reenuux]

Les règles sont en générale des restrictions, des limites. Il me semble que l'une des caractéristiques de l'informatique est justement les brises frontières. Et les grands inovateurs dans le secteur informatique, sont généralement les excpetions aux règles.
Qui te dis que ce n'est pas en facebookand par exemple que je capterai mon inspiration? Ou que mon group facebook est justement celui des développeur?
Je ne suis pas pour les règles dans le monde du développement en ce qui concerne son comportement. Il y a tellement des paramètres en prendre en compte.
Je préfère qu'on parle de conseils aux débutants développeurs. ça me semble plus souple.

[sybil]

Se coucher tôt le soir, les bonnes idées en programmation ont lieue entre 6h et 11h AM.

[tomlev]

Se coucher tôt le soir, les bonnes idées en programmation ont lieue entre 6h et 11h AM.

Pour toi peut-être... pour moi c'est plutôt entre minuit et 3h du mat'

[fregolo52]

Se coucher tôt le soir, les bonnes idées en programmation ont lieue entre 6h et 11h AM.

Je dirais c'est une question de durée pas d'heure.
Passé une certaine durée, l'esprit n'est plus assez concentré, donc c'est source de code pourri (c'est valable pour tout le monde, pas que les débutants).

[el_slapper]

(.../...)Ce que je rejette c'est d'indiquer comme règle d'or de la qualité de commenter, commenter et toujours commenter, cela fait s'écarter des vrais problématiques et du coup n'aide pas à l'amélioration du code
Mais je ne dis pas non plus "Fais du code propre et ne mets aucun commentaire", mais plutôt "efforce-toi à ne pas avoir recours aux commentaires" (autrement dit "concentre toi sur l'écriture de bon code"), dès lors qu'en tout dernier recours, la mort dans l'âme, tu écris ton commentaire qui aurait pu être éviter mais que tu as vraiment tout essayé avant et sais que ça pourra être (ou plutot sera) revu ultérieurement, alors là OK, l'amélioration du code est en bonne voix
(.../...)

J'ai mis +1, parceque c'est une intervention de qualité, mais je ne suis pas totalement d'accord. Comme je reviens de vacances, j'ai plein d'idées, et l'une d'entre elles est que tous les cerveaux humains ne fonctionnent pas de la même manière. Une des clefs de la pédagogie, c'est la répétition - de différentes manières. La tautologie, si on veut.

Je suis d'accord pour dire qu'il faut chercher à faire un code qui n'aie pas besoin de commenter. Parfois, j'y arrive. Pas aussi souvent que je le souhaiterais. Pourtant, même dans ce cas, j'explique quand même le pourquoi de la chose en commentaires. Parcequ'un bon code, au final, c'est un code pédagogique : il enseigne à son lecteur(qui peut être son auteur aussi, mais qui a tout oublié) ce qu'il fait. Et deux formulations valent mieux qu'une.

Le truc a éviter(mais je crois que tout le monde a dit la même chose), c'est le classique :

Code :

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

1
2
'Fonction de conversion d'ASCII vers EBCDIC
Function ConversionASCIIversEBCDIC(Chaine as String) as String

qui n'apporte rien, et se contente de polluer.

Par contre, un commentaire de contexte, du genre :

Code :

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

1
2
3
4
5
6
'Pour passer du format ASCII utilisé par Windows au format EBCDIC utilisé par MVS
'cette fonction assure la conversion idoine
'NB : une chaine convertie par cette fonction devra être transférée au format binaire sous MVS
'cette conversion suivie d'un transfert binaire assure une conservation des caractères spéciaux sous MVS
'elle conserve la longueur de la chaine en entrée
Function ConversionASCIIversEBCDIC(Chaine as String) as String

me parait important.

"ConversionASCIIversEBCDIC" me parait suffisant pour dire ce que fait la fonction. En soi, le code est auto-commenté - je convertis de l'ASCII en EBCDIC. Mais le contexte d'utilisation, à savoir à quel usage on doit se servir de la fonction en question, lui, ne peut en aucun cas être auto-commenté.

Si demain quelqu'un récupère mon code, il saura tout de suite dans quel contexte il peut réutiliser ma fonction, à quoi elle sert, voire même ça pourra lui donner des idées répondant à ses besoins du moment. Sans même se faire suer à lire le code - qui est assez pénible par ailleurs(je ne parviens pas toujours à faire aussi sexy que je ne le souhaiterais). Et, plus subtil, sans même savoir exactement ce que sont l'ASCII et l'EBCDIC, rien qu'en lisant le commentaire, il saura dans quel contexte ils sont utilisés.

[kisitomomotene]

Code :

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

1
2
3
4
5
6
'Pour passer du format ASCII utilisé par Windows au format EBCDIC utilisé par MVS
'cette fonction assure la conversion idoine
'NB : une chaine convertie par cette fonction devra être transférée au format binaire sous MVS
'cette conversion suivie d'un transfert binaire assure une conservation des caractères spéciaux sous MVS
'elle conserve la longueur de la chaine en entrée
Function ConversionASCIIversEBCDIC(Chaine as String) as String

me parait important.

"ConversionASCIIversEBCDIC" me parait suffisant pour dire ce que fait la fonction. En soi, le code est auto-commenté - je convertis de l'ASCII en EBCDIC. Mais le contexte d'utilisation, à savoir à quel usage on doit se servir de la fonction en question, lui, ne peut en aucun cas être auto-commenté.
.

Si je peux me permettre de tirer un conclusion de ce débat pro/anti commentaire qui pourrait mettre tout le monde (presque) d'accord
- Il y a des commentaires inutiles et des commentaires utiles.
- Cela ne vaut pas la peine d'écrire un commentaire inutile juste parcequ’il faut écrire des commentaires
- Un commentaire doit être un complément et non une répétition du code

[Luckyluke34]

Code :

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

1
2
3
4
5
6
'Pour passer du format ASCII utilisé par Windows au format EBCDIC utilisé par MVS
'cette fonction assure la conversion idoine
'NB : une chaine convertie par cette fonction devra être transférée au format binaire sous MVS
'cette conversion suivie d'un transfert binaire assure une conservation des caractères spéciaux sous MVS
'elle conserve la longueur de la chaine en entrée
Function ConversionASCIIversEBCDIC(Chaine as String) as String

Tant qu'à faire d'avoir ce genre de descriptions fonctionnelles à maintenir synchro avec ce que fait vraiment le code, autant que ça soit des tests unitaires, non ?

Chaque phrase de ton commentaire = un TU => moins de "bruit" dans le code et des fonctionnalités vérifiables à tout moment...

[deuz59]

Les règles sont en générale des restrictions, des limites. Il me semble que l'une des caractéristiques de l'informatique est justement les brises frontières. Et les grands inovateurs dans le secteur informatique, sont généralement les excpetions aux règles.
Qui te dis que ce n'est pas en facebookand par exemple que je capterai mon inspiration? Ou que mon group facebook est justement celui des développeur?
Je ne suis pas pour les règles dans le monde du développement en ce qui concerne son comportement. Il y a tellement des paramètres en prendre en compte.
Je préfère qu'on parle de conseils aux débutants développeurs. ça me semble plus souple.

Les règles fixes des limites, des restrictions pour éviter l'anarchie et permettre la vie en communauté....c'est pareil pour l'informatique.

En effet je vois pas l'intérêt de règle pour un artiste qui coderait dans le but d'exposer son code en Gallerie d'art ou pour quelqu'un qui code seul pour son plaisir

Mais en entreprise sans règle, tu t'en mords vite les doigts, les conséquences peuvent être dramatique, un projet qui n'abouti pas, un projet qui part à la concurrence....ce qui va à l'encontre des intérêts de l'entreprise donc OUI il faut coder proprement et pour ce faire collectivement (je connais pas de projets développé/maintenu par une seule personne durant toute sa vie) des règles sont indispensables

[deuz59]

Tant qu'à faire d'avoir ce genre de descriptions fonctionnelles à maintenir synchro avec ce que fait vraiment le code, autant que ça soit des tests unitaires, non ?

Chaque phrase de ton commentaire = un TU => moins de "bruit" dans le code et des fonctionnalités vérifiables à tout moment...

+1

C'est justement un exemple de commentaire qui n'a pas sa place dans le code...à la limite une fonction qui utilise celle ci puis déplace en binaire le résultat avec un commentaire pour indiquer qu'il est impératif de le faire en binaire pour conserver les caractères spéciaux serait un exemple d'utilisation un peu moins pire ....mais un test unitaire qui teste ce cas spécifiquement demeure le must

[kisitomomotene]

Tant qu'à faire d'avoir ce genre de descriptions fonctionnelles à maintenir synchro avec ce que fait vraiment le code, autant que ça soit des tests unitaires, non ?

Chaque phrase de ton commentaire = un TU => moins de "bruit" dans le code et des fonctionnalités vérifiables à tout moment...

Non vous, vous voyez les tests unitaires partout!. L'exemple qu'il a donné si j'ai bien compris donne juste quelques recommandation pour une possibilité d'utilisation du résultat de son code.
S'il doit ecrire un test pour son code, il doit se limiter juste à s'assurer que la conversion de ASCII vers EBCDIC fonctionne correctement. S'il faut maintenant transférer le résultat EBCDIC vers MVS, ce n'est pas cela l'objectif de son code, donc écrire un test pour cela n'a aucun sens. On teste quoi? le transfert d'un format EBCDIC vers MVS? est ce que c'est cela qui lui a été demandé?

On doit bien définir le périmètre de son travail, ne coder et tester que ce qui se trouve dans ce périmètre, et justement toute sorti du périmètre du travail doit faire l'objet d'un simple commentaire, mais aucun code!

[el_slapper]

+1

C'est justement un exemple de commentaire qui n'a pas sa place dans le code...à la limite une fonction qui utilise celle ci puis déplace en binaire le résultat avec un commentaire pour indiquer qu'il est impératif de le faire en binaire pour conserver les caractères spéciaux serait un exemple d'utilisation un peu moins pire ....mais un test unitaire qui teste ce cas spécifiquement demeure le must

Ahem.

Qu'est-ce qui te dis que j'ai la main sur le transfert?

Surtout, sachant que c'est du code VBA, et que je n'ai pas d'outillage pour, depuis VBA, aller lire le résultat sous MVS, comment je teste ce genre de clowneries? non, Kiso

Je ne dis pas que les TU automatiques, c'est le mal. J'en mets quand je peux. Simplement, il y a des cas que les TU ne peuvent pas couvrir. Presque toujours. Là, le TU vérifie juste que la chaine convertie est d'équerre avec la chaine en entrée. Parceque c'est tout ce que fait la fonction.

Kisitomomotene a bien compris le sens de ma démarche : le commentaire est là pour aller au delà du code, pas pour paraphraser le code. Le TU, lui, paraphrase le code : ma fonction fait une traduction, le TU vérifie la traduction. Le TU n'a pas à faire le transfert. D'une part je n'en ai pas les moyens, d'autre part, même si j'en avais les moyens, le TU deviendrait dépendant de l'outillage de transfert si il existait. Le jour ou on change de terminal MVS, il faut alors réécrire le TU... alors que la fonction n'a pas bougé d'un iota. C'est de la sur-ingéniérie.

Donc, je reprends pour faire bref : le commentaire ne se substitue ni au code ni au TU(qui lui, en effet, doit y coller, sur ce point là je suis d'accord). Il permet de replacer un élément dans son contexte, et de comprendre ce que ça fout là sans se taper tout le code qui va avec. En bon français avec des vrais mots. Quand on fait de la maintenance(et j'ai eu à maintenir puis refondre du code de 35 ans d'âge, c'est très formateur), c'est essentiel pour savoir ou on doit chercher.

Effectivement, une fois qu'on sait quel composant il faut modifier(ou réutiliser, ma fonction de conversion n'est pas prête d'évoluer, je crois), les commentaires ne sont plus très utiles. Mais pour le trouver, là, oui, avoir des commentaires explicatifs de la raison d'être du composant, c'est vraiment utile. Et, encore une fois, complémentaire.

[Luckyluke34]

S'il doit ecrire un test pour son code, il doit se limiter juste à s'assurer que la conversion de ASCII vers EBCDIC fonctionne correctement.

Et "elle conserve la longueur de la chaine en entrée" (dernière ligne de commentaire) ? Ca ne devrait pas faire l'objet d'une méthode de test ?
Je ne connais pas le contexte mais peut-être que "assure une conservation des caractères spéciaux" pourrait aussi être transformé en test...

J'ai peut être mal lu les commentaires mais il me semble qu'au grand minimum 2 lignes sont inutiles : la 2 (vu le nom de la fonction on se doute que ça va convertir...) et la 5 transformable en TU.

Le commentaire est pour moi l'ennemi d'une lisibilité fluide du code et connait en général en plus une obsolescence rapide. Pour la navigation dans la base de code (lors du développement, debug, refactoring, etc), je préfère me laisser guider par l'expressivité des noms de classes, variables... phase pendant laquelle trop de commentaires embrouillent l'oeil. Et pour la documentation du comportement attendu de chaque unité de code, les TU (ainsi que de la doc d'architecture ou décrivant la communication entre composants/système tiers comme dans l'exemple de MVS) sont idéaux.

[kisitomomotene]

Et "elle conserve la longueur de la chaine en entrée" (dernière ligne de commentaire) ? Ca ne devrait pas faire l'objet d'une méthode de test ?
Je ne connais pas le contexte mais peut-être que "assure une conservation des caractères spéciaux" pourrait aussi être transformé en test...

Ce n'est pas ce bout de ligne que tu cites qui est l'essentiel du message de el_slapper. Il a tout simplement voulu dire si on veut donner une information qu'on estime importante mais qui ne se trouve pas dans le périmètre de ce qu'on doit développer, il faudrait écrire un commentaire. Ecrire un test c'est un peu absurde dans cette situation.

je redonne un exemple toujours dans le même sens:

Code :

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

1
2
3
4
5
6
/**
* Pour lire le texte rtf converti dans un traitement de texte, il est conseillé *de le mettre à la taille 20, et d'utiliser la police Arial
*/
String convertirAsciiEnRtf(String texteAconvertir){
}

Vous allez écrire un test unitaire de ce commentaire? donc Vous allez développer un traitement de texte, tester sa mise en forme, juste pour dire qu'il faut mettre le texte en gras si on veut correctement le lire?

[lod101]

Si je peux me permettre de tirer un conclusion de ce débat pro/anti commentaire qui pourrait mettre tout le monde (presque) d'accord
- Il y a des commentaires inutiles et des commentaires utiles.
- Cela ne vaut pas la peine d'écrire un commentaire inutile juste parcequ’il faut écrire des commentaires
- Un commentaire doit être un complément et non une répétition du code

Vue le fil de la discussion, on semble en effet s'orienter vers ce compromis. Cette règle, il me semble, est assez générale pour satisfaire tout le monde, non ?.
Concernant "une conclusion", là ça pas l'air d'être encore gagné Et on voit bien qu'une règle finalement ne résoud pas le problème. Chacun y va de sa propre expérience pour s'en accomoder. C'est pas gagné pour notre "débutant" !!! (sujet initial de la discussion)

...Le commentaire est pour moi l'ennemi d'une lisibilité fluide du code et connait en général en plus une obsolescence rapide.

Autant j'ai beaucoup lu de commentaires inutiles ou incompréhensibles mais rarement obsolètes. (Ca reste très liè à l'experience de chacun bient entendu)

...je préfère me laisser guider par l'expressivité des noms de classes, variables... phase pendant laquelle trop de commentaires embrouillent l'oeil.

Je reste sceptique sur le mot "expressivité" quand on parle de lignes de code. Je l'ai déjà dit précedemment, et cela reste très personnel, mais ce code "littéraire" ne représente pas la majorité du code que j'écris ou que je lis (bon d'accord j'ai peut être pas les bonnes références).
J'essaie d'utiliser des "Is...", des "Has...", des "Can..." sur des noms de variables booléennes par exempe, c'est plus expressif en effet, mais y a toujours des particularités, des subtilités pour lesquelles mes "références littéraires" et mon vocabulaire ne suffisent pas (en gros, j'ai toujours un bout de code qui "pue" quoi !!!). Tu ne tombes jamais sur ce genre de casse-tête, où la seule possibilité pour que ton code soit compréhensible est de commenter ?

[deuz59]

Non vous, vous voyez les tests unitaires partout!. L'exemple qu'il a donné si j'ai bien compris donne juste quelques recommandation pour une possibilité d'utilisation du résultat de son code.
S'il doit ecrire un test pour son code, il doit se limiter juste à s'assurer que la conversion de ASCII vers EBCDIC fonctionne correctement. S'il faut maintenant transférer le résultat EBCDIC vers MVS, ce n'est pas cela l'objectif de son code, donc écrire un test pour cela n'a aucun sens. On teste quoi? le transfert d'un format EBCDIC vers MVS? est ce que c'est cela qui lui a été demandé?

On doit bien définir le périmètre de son travail, ne coder et tester que ce qui se trouve dans ce périmètre, et justement toute sorti du périmètre du travail doit faire l'objet d'un simple commentaire, mais aucun code!

Entièrement d'accord....sauf sur la conclusion
==> si tu ne dois pas le coder, ni le tester alors le commentaire est totalement inutile !!!

[deuz59]

Là, le TU vérifie juste que la chaine convertie est d'équerre avec la chaine en entrée. Parceque c'est tout ce que fait la fonction.

On est bien d'accord, ce TU est suffisant, et comme la fonction ne fait rien d'autre, le commentaire associé est mal placé !

Kisitomomotene a bien compris le sens de ma démarche : le commentaire est là pour aller au delà du code, pas pour paraphraser le code.

Le but est d'écrire du bon code, et l'effort doit être fourni pour le code à écrire pas pour aller "au-delà"

Le TU, lui, paraphrase le code : ma fonction fait une traduction, le TU vérifie la traduction. Le TU n'a pas à faire le transfert. D'une part je n'en ai pas les moyens, d'autre part, même si j'en avais les moyens, le TU deviendrait dépendant de l'outillage de transfert si il existait. Le jour ou on change de terminal MVS, il faut alors réécrire le TU... alors que la fonction n'a pas bougé d'un iota. C'est de la sur-ingéniérie.

Tout à fait, et pour la même raison qu'il n'y a pas besoin de TU, le commentaire est inutile. Le jour où cette fonctionnalité devra être développée alors là tu pourras écrire son TU...qui servira justement à valider que la fonctionnalité continue à faire ce qu'on lui demande lorsque tu décideras de changer l'outillage pour le transfert ....et le commentaire ne servira toujours à rien !!!

Quand on fait de la maintenance(et j'ai eu à maintenir puis refondre du code de 35 ans d'âge, c'est très formateur), c'est essentiel pour savoir ou on doit chercher.

On parle de règle à appliquer pour un débutant (ou pas) à notre époque, avec les moyens à notre dispo aujourdh'ui et avec le recul (là encore on retrouve l'expérience qui dicte les bonnes pratiques)...sûr que dans les programmes "d'antan" la règle de tout commenter était beaucoup plus légitime

Effectivement, une fois qu'on sait quel composant il faut modifier(ou réutiliser, ma fonction de conversion n'est pas prête d'évoluer, je crois), les commentaires ne sont plus très utiles. Mais pour le trouver, là, oui, avoir des commentaires explicatifs de la raison d'être du composant, c'est vraiment utile. Et, encore une fois, complémentaire.

Si c'est cette fonction que tu dois modifier, tu l'auras trouver en même temps que son commentaire, donc plus besoin de commentaire (c'est comme enterrer une carte au trésor avec son trésor : aucun intérêt !!)

[deuz59]

Se coucher tôt le soir, les bonnes idées en programmation ont lieue entre 6h et 11h AM.

Je dirais surtout de prendre beaucoup de douches

[deuz59]

je redonne un exemple toujours dans le même sens:

Code :

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

1
2
3
4
5
6
/**
* Pour lire le texte rtf converti dans un traitement de texte, il est conseillé *de le mettre à la taille 20, et d'utiliser la police Arial
*/
String convertirAsciiEnRtf(String texteAconvertir){
}

Vous allez écrire un test unitaire de ce commentaire? donc Vous allez développer un traitement de texte, tester sa mise en forme, juste pour dire qu'il faut mettre le texte en gras si on veut correctement le lire?

Ni TU, Ni commentaire...qu'apporte une fois de plus ce commentaire (il fait juste présager d'une utilisation incertaine en limitant d'ores et déjà celle-ci, donc complètement superflux) ???
Donner un "conseil" n'a pas sa place ici...comme tu l'indiques on va pas développer un traitement de texte...le jour où on serait amener à le faire et si le résultat doit être lisible, alors le TU vérifierait que c'est bien le cas (que tu utilises la fonction convertirAsciiEnRtf ou pas, en lui passant ou pas un texte arial taille 20)

[Luckyluke34]

Code :

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

1
2
3
4
5
6
/**
* Pour lire le texte rtf converti dans un traitement de texte, il est conseillé *de le mettre à la taille 20, et d'utiliser la police Arial
*/
String convertirAsciiEnRtf(String texteAconvertir){
}

Vous allez écrire un test unitaire de ce commentaire? donc Vous allez développer un traitement de texte, tester sa mise en forme, juste pour dire qu'il faut mettre le texte en gras si on veut correctement le lire?

Non, car c'est un exemple très mal choisi, qui devrait être dans une doc utilisateur et n'a rien à faire dans du code, que ça soit commentaire ou TU

Autant j'ai beaucoup lu de commentaires inutiles ou incompréhensibles mais rarement obsolètes. (Ca reste très liè à l'experience de chacun bient entendu)

Ben moi, j'en vois souvent. Le renommage d'une classe, d'une notion, un changement de paramètre, l'externalisation d'une responsabilité dans un autre objet... autant de changements qui font que les commentaires sont très sujets à effets de bord et ne sont plus valables dès qu'on modifie quelque chose dans le bout de code commenté ou ailleurs.

J'essaie d'utiliser des "Is...", des "Has...", des "Can..." sur des noms de variables booléennes par exempe, c'est plus expressif en effet, mais y a toujours des particularités, des subtilités pour lesquelles mes "références littéraires" et mon vocabulaire ne suffisent pas (en gros, j'ai toujours un bout de code qui "pue" quoi !!!). Tu ne tombes jamais sur ce genre de casse-tête, où la seule possibilité pour que ton code soit compréhensible est de commenter ?

Si, mais c'est rare et il s'agit le plus souvent d'explications d'algorithmes complexes à comprendre pour le commun des mortels (cryptographie, notions mathématiques...).
Sinon, comme tu le dis toi-même, un code peu expressif est un code qui pue car ce qu'il représente sera ambigu pour un développeur qui passera par là.
Et ta référence au vocabulaire est très intéressante. J'ai tendance à penser qu'un vocabulaire métier commun à toute l'équipe de dev et aux experts métiers est indispensable, et que ce lexique doit absolument se retrouver dans le code (c'est ce qui est préconisé dans Domain Driven Design avec la notion d'ubiquitous language). De cette façon, le nommage des classes, méthodes, services... se fait beaucoup plus naturellement et sans équivoque.