Reprise du message précédent :
Hors contexte ça me semble pas trop délirant perso. Soit le nom de la classe est explicite, soit c'est pas clair et je m'attendrais à de la documentation plutôt qu'un simple commentaire qui n'est pas référencé.

Nan mais du code ça se commente, point.
 
Ça ne coûte absolument rien en terme de resource et ça peut rendre service.
 
Et à la lecture de ce qu'il écrit, je doute que ce soit un commentaire "A class to make coffee" sur une classe qui se nomme "MakeCoffee"

https://www.youtube.com/watch?v=7VCYBtx6h4g
votre garagiste, il met combien de temps à changer les pneus neige déjà ?

le temps facturé en main d'oeuvre ou le temps réellement passé ?

Je suis absolument pas d'accord. À la louche 95% de notre codebase a zéro commentaires et ça pose aucun problème.

https://blog.codinghorror.com/coding-without-comments/

Ben non il n'est pas explicite du tout, justement. Et de la doc, c'est bien simple, il n'y en a pas.

Voila.

Hors contexte, j'aurai tendance à dire qu'il vaut mieux renommer la classe dans ce cas. Parce que quand la classe est utilisée, t'as pas vraiment envie d'aller voir le commentaire associée pour découvrir ce qu'elle fait.

Ca, c'est même pas envisageable.

 
Non mais je voulais pas dire que tout se commente, je me suis mal exprimé. Comme je disais, si ta classe se nomme "MakeCoffee" t'as pas besoin de mettre un commentaire "Make coffee".
 
Donc en l'occurrence je trouve ça con de vouloir faire enlever un commentaire avec comme prétexte "le nom de la classe est suffisamment explicite".
 
Oh puis merde

Le problème, il n'est pas dans le fait ou non de commenter la classe (ce qui est nécessaire dans le cas que je mentionne), le problème est l'utilisation de la revue de code pour asseoir un pouvoir factice.
 
C'est tout ce qu'il ne faut pas faire avec la revue de code. Quand j'en faisais, je laissais passer les trucs sans importance, du moment qu'ils n'affectaient pas la lisibilité générale. Parce que quand la revue de code se transforme en exercice de flicage et qu'on enlève toute créativité et pouvoir de décision au développeur, ça devient vite assez insupportable.

J'avoue que je me suis écarté sur sujet (edit: et je suis plutôt d'accord)

 
2001-2002

C'est sur la chaîne de DHL et le premier commentaire :  

 
Le point en gras est complètement faux.
Un commentaire c'est exactement la même chose que du code : ça prend du temps à écrire et ça prend du temps à maintenir.
Les meilleurs commentaires sont ceux qui ne sont pas nécessaires, avec des noms explicites et un découpage de code proprement effectué.  
Il doit y en avoir le moins possible dans une application bien faite et surtout ils doivent être à jour : pire que l'absence de commentaire, un commentaire obsolète.
 
Donc non, du code ça ne se commente pas systématiquement. Muchacho a largement assez d'expérience pour savoir ce qu'il est nécessaire de commenter ou pas, mais en gros mettre des commentaires partout est fortement contre-productif.
 
 

 
Une documentation qui n'est pas issue du code ? Tu veux dire le truc qui n'est plus à jour depuis 6 mois ?

 
Oui enfin dans son cas, le commentaire est déjà écrit... donc revenir dessus c'est contre productif

Mon garagiste il a levé ma voiture sur la feuillure jusqu'à ce que 2 roues soient en l'air, et après il a fait l'autre côté idem
Depuis je le fais moi-même, sans me presser c'est une grosse demie-heure
 
Pour en revenir à WilliamsF1, ça ne se passe pas toujours aussi bien : https://www.youtube.com/watch?v=TuS0oaC2wJI https://www.youtube.com/watch?v=jfHJzVpfjeI
Mais il faut reconnaître qu'ils ont fait des progrès stupéfiants pendant l'intersaison : les mécanos sont passés de franchement pas bons (en nombre de boulettes et en rapidité) à top du top

Non non, de la javadoc par exemple.

Par contre un commentaire simple en en-tête d'une classe je vais aussi faire remarquer à l'auteur que ça sert à rien.

Surtout écrire un paragraphe de 4 lignes pour t'expliquer que ANeedleSequenceBuilder, c'est totalement évident que ça sert à la décontamination et que ce n'est donc pas la peine de le préciser. Sachant que les aiguilles en question ne servent évidemment pas qu'à être décontaminées. Donc si c'est évident pour le relecteur, - qui s'avère aussi être aussi l'auteur initial de la classe, sans doute la raison pour laquelle je dois justifier la moindre modification... son code étant évidemment parfait -, ça doit l'être aussi pour les autres (bien qu'à mes yeux tout à fait incompréhensible). Curieusement, c'est justement à ça que ça sert, les commentaires, surtout dans un projet où "la doc c'est le code".
 
Mais surtout, ça n'est qu'un exemple parmi tant d'autres. Un développeur d'une autre équipe, qui a eu droit à une revue de code par cette personne, a répondu sur la revue (avec l'approbation de son propre chef) que la plupart des remarques étaient de la perte de temps pour tout le monde et qu'elle passerait moins de temps à corriger elle-même qu'à écrire des commentaires dans la relecture. J'avoue que j'ai rigolé intérieurement.

Tiens bah sondage : votre avis sur vos qualiticiens ?

Ils mangent tout seul leur saucisse-lentilles le midi à la cantine de la cogip, et c'est très bien comme ça.

Jamais vu quelqu'un autant payé à rien foutre. La _seule_ chose qu'il ait fait en deux ans c'est recopier les indicateurs sonar sur un PowerPoint et dire en revue si ça lui va ou pas. Je sais même pas à quoi est censé rassembler son travail.

C'est assez bien résumé.

Pour répondre un peu plus sérieusement, dans notre métier niveau qualité il faut mettre la  tune dans les tests. Quelqu'un qui teste à la main, puis quelqu'un qui s'occupe d'automatiser et maintenir les tests les plus chiants (genre UI et matériel ). Sauf que dans la tête de beaucoup de monde la qualité c'est la gestion des procédures et des docs.

 
Je ne comprends pas ce mot.

 
Ah je comprends.
 
Bon ben ça se passe comme tu décris initialement chez nous. Je bosse pour que cette équipe ne grossit pas, mais ils sont bien utiles.

 
Non, pas forcément. C'est comme si tu disais que revenir sur (mauvais) code c'est contre-productif parce qu'il est déjà écrit.
La dette technique c'est contre-productif ça par contre et c'est pas une vue de l'esprit.
 
Après encore une fois je ne porte pas de jugement définitif sur le cas précis pointé par much, c'est le mieux placé pour le faire.
 

 
Oui, exact.
Après perso les seuls commentaires non-javadoc présents dans le code sont dans des blocs de code, pas en dehors.

Ils m'envoient des bug reports donc c'est qu'ils travaillent mieux que moi

 
Je comprends bien ton point de vue, et je suis assez d'accord. Sauf que ce n'est pas comparable à revenir sur du mauvais code. Là le problème ne semble pas être que le commentaire ne décrit pas correctement la classe... mais qu'il n'apporte rien à ce que le nom de la classe laisse supposer. Enfin de toute façon dans le cas de much, je pense que c'est vraiment plus de branlage de nouille qu'autre chose.

Si un commentaire n'apporte réellement rien, c'est du bruit et il doit être supprimé du code. C'est de la dette, certes moins importante qu'une dette de code, mais de la dette quand même.

Le code doit être le plus explicite possible par son nommage et sa structure, les seuls commentaires utiles sont les préconditions/postconditions des méthodes pour moi. Le reste c'est cautère sur jambe de bois (pour pas rendre le code plus explicite) ou dangers (commentaires trompeurs car pas mis à jour quand le code a évolué)

0x5f3759df

En quoi ça a du sens de mettre ces trucs en commentaires exactement? Ça me semble encore plus con que le reste.

 
Irrelevant pour des good practices, ça concerne très peu de code ce genre de magic number utilisé dans les approximations mathématiques.
 
 

 
Tu rappelles le contrat que doit respecter ta fonction   C'est ce que tu veux savoir quand tu vas lire cette fonction, elle prend quoi en entrée/sortie (t'as sa signature) et elle a quel impact.

Ceci dit, j'aime bien faire en sorte que mes préconditions elles soient validées par le code lui-même. Soit je suis dans le cas d'une API publique (y compris "publique" uniquement au sein de l'appli dans le cas des dépendances internes) et il y a javadoc obligatoire, soit je ne documente pas les préconditions avec les commentaires mais avec des assertions ou des annotations dédiées (@Nullable ou @Nonnull en Java par exemple) quand c'est utile.

je cherche des conseils pour:
 
- clavier et souris sans-fil robustes
- pas une forme trop tordue pour la souris (je suis gaucher comme Obama )
- qui marche sous nulix
- usage bureautique (pas de jeux, pas de FPS)
- qui a une bonne autonomie et/ou qui se recharge facilement
- pour le prix j'ai les moyens (...du moment que la qualité justifie le prix... je ne suis pas un pigeon non plus...)

Kit logitech? Il y en a avec sours ambidextres genre MK235 ou MK270.

Pourquoi un clavier sans-fil?

 
Le use case en général c'est "j'ai envie de me ballader dans la pièce" / "aller loin de l'écran".

ou bien : j'ai pas envie de m'emmerder avec des fils sur mon bureau

Clavier:  Logitech K800, imbatable !

https://www.amazon.fr/Logitech-Wire [...] B0041D81TO

Super agréable, silencieux, costaud voire increvable je pense, rétroéclairé, très bonne autonomie, rechargeable en micro usb, SAV Logitech.

Ca fait 6 ans que je l'ai, pour mon PC du salon, il a pas vieilli d'un chouilla, pourtant il est tombé et s'est pris des coups à plusieurs reprise !

bof. Le mien n'a pas tenu : 2 touches en vrac, et pas moyen de le réparer.
 
Là,j'ai un Keysonic ACK56000 AL depuis 4 ans, utilisé intensivement ua taf, ça marche bien.