Pour revenir sur le tout anglais, c’est une solution mais attention tout de même. Quand on travaille dans des domaines techniques pointus, nos chers utilisateurs ont un certain vocabulaire (français, anglais voir même franglais !), si on utilise des termes traduit assez différents pour qu’ils ne soient pas parlant, ça peut poser des problèmes. Il faut alors mettre en place une table de traduction documentée et c’est pas franchement pratique à tenir à jour ou même à consulter.

Sans compter que tant qu’à traduire, autant traduire juste et c’est pas donné à tout le monde (même à Harraps!). Un cas qui me vient à l’esprit car je bosse dessus : Mesure d’épaisseur limite se traduit en “Wall thickness measurement”, ce n’est pas littérale.

@Nico&Alex pour le “is” je ne dis pas de ne pas l’utiliser … mais faut se méfier c’est tout ce que je dis.

@Nico pour Checkstyle t’es un peu trop Agile … ok tu le desactives pas … tu te demmerdes pour qu’il soit en cohérence avec tes règles. C’est bien parfois … ou pas … parce que du coup c’est plus cohérent avec celles des autres.

Enfin pour l’algo ben ca dépend si c’est juste un truc super simple compréhensible par le premier venu ok j’adhère. Maintenant si tu bosses avec des calculs un peu complexe, des variables pas forcément parlantes car résultats de calculs intermédiaires etc… ben ton code est incompréhensible, et un peu d’algo ça aide à éclaircir le truc.

J’ai un exemple en tête sur des calculs de coordonnées sur une grille formée d’hexagones en fonction de coordonnée x/y classiques … bref il faut déterminer des pentes de droites, des décalages de position etc.
Il y a plein de modulo, arrondis, de largeur/2 ou autres hauteur/3 etc.
Quelqu’un qui ne s’est pas un peu plongé dans la problématique ne comprendra rien au code … avec une ligne pour dire ce que l’on calcul et pourquoi, ça devient plus clair.

Bref pour moi ca dépend de pas mal de choses jedis pas qu’il faut absolument laisser son pseudo algo … je dis que parfois ca aide, et que parfois tout ne peut pas être mis dans la javadoc.
Pour moi la javadoc indique surtout ce que fais la méthode mais pas comment elle le fait dans le détail non plus. Quand on l’utilise on s’en fout de savoir toutes les étapes internes… par contre en debug ou en évolution on est content de comprendre ce qu’a voulu faire le gus précédent et pourquoi.

Comme tu disais au final ça reste une question de bon sens, on est d’accord la dessus.

Pour le point 3°, c’est ton habitude ok, mais c’est franchement pas quelquechose que je conseillerai. Personnellement si l’algo parle de lui même je vois pas pourquoi laisser la polution du commentaire qui t’as permis d’en venir à écrire cela. Là c’est vraiment une question de point de vue.

Par contre je vois pas où tu as vu que je désactivai checkstyle!!! C’est un outil indispensable pour vérifier la cohérence du code source avec les conventions. Et je l’utilise tout le temps. Après, étant adepte du refactorring permanent, si y’avait des règles déconnantes …

@Miumius : Bien joué!

@Alex: je rejoins FinalSpy, mieux vaut que la variable s’appelle userValid. (beurk ca me rappelle de mauvais souvenirs cette histoire de struts…)

Les variables booléennes doivent toujours commencer par “is”. Ex : isUserValid. De même, pour les getters associés à un boolean, on ne met pas getUserValid() mais isUserValid()

Les noms des méthodes ne sont jamais un nom mais plutôt un adjectif ou un verbe. Par exemple mailSender(), c’est un nom à la con pour une méthode. Cela ne décrit pas l’action souhaitée. Alors que sendMail(), c’est beaucoup plus parlant.

Bref, je m’arrête là, le reste se trouve dans le livre ‘Code complete’ chez Microsoft Press. Un pavé imbouffable mais vraiement génial.

Et merci d’avoir parlé de la langue des variables, point que j’ai zappé mais qui me tient beaucoup à coeur. Je suis un fervent défenseur du tout anglais, pour deux raisons principales :
- Pouvoir décrire plus de choses facilement avec moins de mots
- Ne pas avoir d’ambiguïtés sur l’accord de participes passés et adjectifs : puisque on ne peut pas mettre d’accents dans le code, on se retrouve parfois avec des incertitude quant au rôle précis de la variable.