Ca se discute ca :)
C'est meme une grosse source de troll.
Le pb avec trop de commentaires, c'est qu'il faut le maintenir ce trop de commentaires.
En pratique, ce qui se passe, c'est que tu vas ecrire une tartine, puis l'oublier cette tartine.
Ensuite, toi ou quelqu'un d'autre va venir, regler un probleme, refactorer ou autre, et va laisser le commentaire inchange (forcement, il influe pas sur le build, et on est presse, faut que ca marche la maintenant).
Et paf, pasteque. Tu te retrouves avec un commentaire qui potentiellement dit le contraire de ce qu'il se passe, au pire, au mieux tu te retrouves avec un commentaire qui veut pas dire grand chose.
Et quand tu reviens encore plus tard (ou qq1 d'autre), tu te dis "mais merde, ca fait pas du tout ce que c'est cense faire... Qui qu'a tord? Qui qu'a raison?" Et hop la, t'es parti pour une demi journee de "bon, on va d'abord voire ce que ca fait precisement, et apres on va faire le tour du bureau pour trouver qui sait pourquoi le commentaire et le code sont desynchronises".
C'est un peu le meme probleme avec les jean jean qui unit testent des getters et setter, tu change un attribut, et t'es parti pour une journee dans une jungle de classes de test de 4000 lignes qui au final ne font que unit tester la fonction "generate getters/setters..." d'eclipse.
Quoi, ca se voit que je suis sur ce genre de probleme a la con depuis ce matin, que j'ai a peine avance d'un poil, et que ca me gonfle ces test unitaires aussi debiles qu'inutiles?
Sans meme parler de la pollution du code. Un commentaire qui dit // iteration variable i c'est juste du bruit. Tout le monde sait ce que i veut dire.
If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.
[^] # Re: Commentaire dans le code
Posté par pasScott pasForstall . En réponse au journal Sortie de Movicon 0.3. Évalué à 3.
C'est meme une grosse source de troll.
Le pb avec trop de commentaires, c'est qu'il faut le maintenir ce trop de commentaires.
En pratique, ce qui se passe, c'est que tu vas ecrire une tartine, puis l'oublier cette tartine.
Ensuite, toi ou quelqu'un d'autre va venir, regler un probleme, refactorer ou autre, et va laisser le commentaire inchange (forcement, il influe pas sur le build, et on est presse, faut que ca marche la maintenant).
Et paf, pasteque. Tu te retrouves avec un commentaire qui potentiellement dit le contraire de ce qu'il se passe, au pire, au mieux tu te retrouves avec un commentaire qui veut pas dire grand chose.
Et quand tu reviens encore plus tard (ou qq1 d'autre), tu te dis "mais merde, ca fait pas du tout ce que c'est cense faire... Qui qu'a tord? Qui qu'a raison?" Et hop la, t'es parti pour une demi journee de "bon, on va d'abord voire ce que ca fait precisement, et apres on va faire le tour du bureau pour trouver qui sait pourquoi le commentaire et le code sont desynchronises".
C'est un peu le meme probleme avec les jean jean qui unit testent des getters et setter, tu change un attribut, et t'es parti pour une journee dans une jungle de classes de test de 4000 lignes qui au final ne font que unit tester la fonction "generate getters/setters..." d'eclipse.
Quoi, ca se voit que je suis sur ce genre de probleme a la con depuis ce matin, que j'ai a peine avance d'un poil, et que ca me gonfle ces test unitaires aussi debiles qu'inutiles?
Sans meme parler de la pollution du code. Un commentaire qui dit // iteration variable i c'est juste du bruit. Tout le monde sait ce que i veut dire.
If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.