@fasteez : je pense que si tu as du code qui est complexe et difficile à suivre, alors il faut « cacher » la partie difficile à l’utilisateur en publiant une API facile. TDD peut bien aider pour cela puisqu’il nous permet de réfléchir au « quoi faire » plutot qu’au « comment faire ». De même, au sein de ton implémentation compliquée/complexe, je suis persuadé qu’il y a des moyens pour redécouper le travail, faire parler le code sans commentaire, simplifier l’implémentation. Mais ce n’est pas facile. C’est même très difficile d’écrire du code lisible sans commentaire (mon coach parle de code « beau à pleurer », sacré objectif !)
Merci pour le lien vers le bouquin : ca m’a l’air intéressant !

Pour l’info il y’a un bouquin assez connu on dirait qui traite du sujet :
http://www.spinellis.gr/codereading/

Et pour conclure je pense que le seul code « non commentable » c’est mini langage specifique interprete car ici pas de projection vers un ensemble de concepts differents. (Oui je suis un futur Lispien =])

Et sinon, c’est pas toi qui faisait des billets sur le Jazz ?

(je suis un professionel de la programmation : je suis payé pour produire du code)

je ne comprends pas le rapport entre le fait que le code considéré soit « pro » ou « amateur » et la présence de commentaires inutiles : à mon avis, du bon code est auto-documenté, même si il est produit par un amateur.

en effet, qu’est qui est plus pratique :

——————-
// commentaire qui explique ce qui suit ?
objet.doTheThingWithoutPrecision(arg1)
——————-

——————-
objet.actionMetier(argumentComprehesible)
——————-

à mon avis, la deuxième solution est la meilleure quel que soit le contexte. lorque le code exprime une intention bien précise, quiconque le relit le comprend aisément. nul besoin d’avoir recours aux commentaires, le flux des instructions se comprend bien. Egalement, l’API se lit facilement si les méthodes « parlent »

Enfin, dans des tests unitaires aussi, il vaut mieux des noms de tests qui parlent (testEntreeUtilisateurNonNumerique_Controle_RenvoieErreurSaisieNumeriqueObligatoire)
plutot que des test1 test2 test3 avec un commentaire au dessus.

De plus, les tests unitaires peuvent commenter une API complexe : pour moi, la meilleure façon d’expliquer, c’est de donner des exemples, et c’est ce que permettent els tests unitaires.

Bref, je voulais juste rajouter un petit message car décidément, cette vision des commentaires me fait réfléchir…

C’est surtout cette idée de langage parlé qui m’a plus. Je ne suis pas tout a fait d’accord avec cette idée que le langage de programmation à besoin d’être parlé ou d’avoir un support parlé. Cela serait un peut trop bruyant dans ma tête si s’était le cas . Après un certain niveau de pratique, le langage de programmation utilisé devient une compétence inconsciente. De la même manière qu’on conduit une voiture sans réfléchir au levier de vitesse ou à l’accélérateur. Vous n’êtes pas en permanence à vous demander si le frein est en deuxième ou troisième position. Utiliser un langage parlé en plus, c’est comme si on avait besoins de traduire mentalement tout ce qu’on dit en français quand on parle anglais.

Ceci dit, je comprends justement l’argument puisque effectivement quand on début en anglais on pratique souvent cette traduction mentale. Mais il peut être intéressant pour l’amateur d’évoluer vers plus d’ »aisance ».

Enfin, pour répondre à ton message Christian. J’ai l’impression que tu décris ici des programmes « oeuvre d’art » qui auraient un état figé et dont on pourrait en étudier l’histoire, la genèse… Pourquoi pas. J’aime bien aussi quand ça peut servir à quelque choses et s’est vrai qu’a titre personnel je vais plus rechercher dans du code des idées d’architectures, des solutions à des problèmes génériques…

Le code est pour moi quelque chose de vivant, comme un jardin qu’il faut entretenir. Enlever les commentaires faux, c’est comme de retirer les feuilles mortes. Quand je relis du code, j’ai souvent le reflexe de le modifier pour en améliorer l’expressivité, ce qui est différent du travail d’annotation que tu fais sur tes livres, mais qui finalement correspond plus à l’esprit de l’open source non ? Tout le monde peut participer.
Mais là encore je me place dans la position de quelqu’un qui produit le code et non quelqu’un qui le regarde comme on regarde une fourmilières.

Bon aller, je retourne à mon travail de développeur professionnel…