Mon compte sur www.developpez.net est encore très jeune, que déjà je veux me livrer à une agression en règle. De la convention de présentation des codes sources, comme l'a proposée Sun il y a quelques années de cela.
Elle me gêne sur deux points particuliers. L'un est prompt à déclencher des querelles dans les équipes, l'autre me semble appeler les erreurs.
1) Pour déclencher une guerre en une minute? Les accolades ouvrantes de fonction...
50% des développeurs de langages à accolades de la planète écrivent leur code ainsi:
et l'autre:
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2 void toto() { }
Chacun a des arguments à faire valoir qui se respectent ou se discutent.
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3 void toto() { }
L'inconvénient, c'est quand ces considérations normatives viennent à prendre le pas sur d'autres nettement plus importantes telles que la présence de javadoc, de commentaires (différent d'une javadoc!), et d'assertions dans le code source.
Ce principe d'accolades ouvrantes de fonctions proposé par Sun me semble parasitant, et surtout peu fondé.
2) this.mavariable, un voeu pieu qui ne dure jamais bien longtemps
Sun propose que les variables membres de classes soient préfixées par this. là où d'autres suggèrent _ ou m_
Ce code-ci:
est-il correct? Ou bien le développeur réalise en fait concrètement cela, mais a oublié le préfixe this. ?
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2 if (age > ageLimite) throw(new IllegalStateException("Ce fromage ne doit vraiment plus valoir grand-chose, vous savez."));
ou bien même:
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2 if (this.age > ageLimite) throw(new IllegalStateException("Ce fromage ne doit vraiment plus valoir grand-chose, vous savez."));
Un seul moyen de le savoir: se balader dans le reste du code source afin de trouver la trace de possibles variables membres porteuses de ces noms. Et alors, on saura...
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2 if (this.age > this.ageLimite) throw(new IllegalStateException("Ce fromage ne doit vraiment plus valoir grand-chose, vous savez."));
Sous Eclipse, je fais brancher le warning "une variable locale cache une variable membre" et "nous avertir sur les variables inutilisées" dès qu'un développeur désire utiliser cette norme. Et ça ne rate jamais. Le warning se déclenche quinze fois par millier d'instructions. Il a cru affecter sa variable membre, mais n'ayant pas fait attention et ayant oublié de placer this. il ne l'a pas fait et a affecté à sa place une variable locale utilisée dans la fonction à d'autres fins.
Ce point de norme là est, à mes yeux, contreproductif. Il pré-suppose qu'on n'oubliera jamais this. mais n'avertit pas dans le cas contraire. Il est l'origine de nombreuses anomalies. Mais par chance, de moins en moins appliqué (au profit de _ et m_) là où j'observe des codes sources.
Partager