Discussion :

[ptah35]

Le genre de commentaire que, personnellement, je considère justement parfaitement inutile (et je sais de quoi je parle, j'en ai gérer pendant plusieurs années pour un client). La notion d'auteur peut être très vague lorsqu'on est dans une équipe de plusieurs développeurs, voire dans une boite comportant plusieurs équipes de plusieurs développeurs. Et si en plus en considère le turn-over de la boite .... Sauf à y renseigner l'annuaire, ça sert pas à grand chose.
Les notions de modifications, dernière modification, etc, sont souvent rarement à jour au delà de la 4 ou 5ème version du fichier, surtout lorsque les entêtes en question concerne à la fois le fichier lui-même mais aussi chaque méthode dans le fichier.

De plus, dans une structure organisée, qui possède un gestionnaire de source type svn ou github, ce genre de commentaire est rendu obsolète par le gestionnaire de source, bien plus efficace à ce niveau là.

Mais après, effectivement, chacun voit son propre intérêt dans sa façon de faire.

Pour le cas que j'ai eu à gérer durant plusieurs années, sur ce point là et sur la doc qui allait avec, il n'était pas rare qu'il me faille 1/2h pour faire une modif, et ensuite 3 jours pour gérer toutes ces notions de versions, tant dans les sources que sur la doc qu'il fallait modifier entièrement. Sans compter les tests, qui, au delà du test fonctionnel de la modif, consistaient à redérouler l'entièreté des tests pour la non régression, une inspection de code, un file-compare, une relecture complète de la doc, ...
Bref rien de très productif.
Alors qu'avec un gestionnaire de source, il suffit de produire un rapport d'évolution entre les 2 releases, ça prend 30sec !

Pour l'auteur et la date je pensais pour les deux à la dernière modification mais j'admet que ce n'est pas forcément nécessaire, l'information étant effectivement dans le système de gestion de version qui est, selon moi, une absolue nécessité si l'on est professionnel et je ne vois que peu de raison de s'en passer dans les autre cas. Je pense néanmoins qu'une description du contexte dans lequel on utilise le fichier et une brève description de son contenu reste utile. D'une manière générale ce que l'on écrit sous forme de commentaire doit être relativement stable et c'est le cas de la description du contexte d'un fichier, du JavaDoc d'une API qui est publiée ou des pré-conditions, post-conditions et invariants d'une méthode. Mais le principe est :

"Si tu peux le dire en code, dis le en code et utilise les commentaires pour le reste"

A chacun de décider ce qui est utile ou non dans le reste, mais le fait de dire uniquement en code ce qui peut être dit en code évide déjà une bonne partie des commentaires susceptibles de devenir obsolètes.

[Mr_Exal]

Un peu d'humilité ne te ferait pas de mal. Tu ne peux pas évaluer objectivement la lisibilité du code que tu produis. Et si tu penses que tu peux faire lisible sans aucun commentaire, c'est que tu te sur-estimes complètement. Mais ce débat a déjà été fait et refait maintes fois.

Tu te permets de traiter de "guignols" des personnes qui connaissent mieux que toi leur métier.

J'en ai discuté (et montré ce que j'avais produis autant en terme de code que d'oral) avec plusieurs personnes du métier et crois moi oui ce sont deux guignols. Rien qu'à travers les questions qu'ils m'ont posé ils n'ont strictement rien écouté de ce que je leur ai raconté (et crois mois que j'avais passé des oraux blancs devant des personnes ne connaissant pas du tout mon sujet avant, qui ont un QI moyen normal et qui ont tout à fait compris de quoi il s'agissait).

[el_slapper]

J'en ai discuté (et montré ce que j'avais produis autant en terme de code que d'oral) avec plusieurs personnes du métier et crois moi oui ce sont deux guignols. Rien qu'à travers les questions qu'ils m'ont posé ils n'ont strictement rien écouté de ce que je leur ai raconté (et crois mois que j'avais passé des oraux blancs devant des personnes ne connaissant pas du tout mon sujet avant, qui ont un QI moyen normal et qui ont tout à fait compris de quoi il s'agissait).

Je n'aime pas tailler, mais je vais le faire quand même : tu est un mauvais programmeur parceque tu manques cruellement d'humilité. On a toujours plein de trucs à apprendre, y compris de gens qui ne pensent pas comme nous. En partant du principe qu'ils n'ont rien à t'apprendre, alors tu te limites toi-même, dans un univers ou l'apprentissage est essentiel.

[Mr_Exal]

Je n'aime pas tailler, mais je vais le faire quand même : tu est un mauvais programmeur parceque tu manques cruellement d'humilité. On a toujours plein de trucs à apprendre, y compris de gens qui ne pensent pas comme nous. En partant du principe qu'ils n'ont rien à t'apprendre, alors tu te limites toi-même, dans un univers ou l'apprentissage est essentiel.

Je n'appelle pas ça du manque d'humilité, juste savoir faire la part des choses.

Je suis bien conscient que la formation est permanente dans nos métiers et qu'il vaut mieux être ouvert à tout et à chacun.

Seulement, pour entendre les réflexions qu'ils m'ont fait pendant mon oral j'avais un peu autre chose à faire que de me faire casser comme une merde pendant 45 minutes (après, soit, c'était peut être le but de l'exercice, mais même mes profs ont halluciné quand je leur ai raconté ce qu'il s'est passé (des réflexions du genre "Ah c'est ça vos Schémas UML ? Mais c'est de la merde.")).

Je ne vois pas trop en quoi c'est pertinent de se foutre de la gueule du candidat que tu as en face de toi pendant tout le long de son oral et de le casser à chaque fois que tu ouvres ta bouche.

Maintenant j'en suis pas à dire "Bouhouhou les vilains jurys ils ont été méchants."

[troll] Je ne fais pas (encore) de marketing je n'ai pas (encore) besoin d'étudier les cons pour chercher à comprendre comment ils fonctionnent. [/troll]

[alyno]

Tout réside dans la motivation, et aussi à la l'implication de la personne, comme aider des gens en difficulté dans des forums.
Parce que avoir le sentiment d'apporter son aide nous permet aussi d'apprendre des choses plus vite qu'on ne peut l'imaginer.
C'est pourquoi je suis du même avis que Mr Eric Lippert

[Laurent 1973]

Codez en imaginant que la personne qui va maintenir votre code est un psychopathe meurtrier qui connaît votre adresse.