Je trouve la convention de présentation de code source proposée par Sun criticable.

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:

Code:

---

1 2	void toto() { }

---

et l'autre:

Code:

---

1 2 3

void toto() { }

---

Chacun a des arguments à faire valoir qui se respectent ou se discutent.
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:

Code:

---

1 2	if (age > ageLimite) throw(new IllegalStateException("Ce fromage ne doit vraiment plus valoir grand-chose, vous savez."));

---

est-il correct? Ou bien le développeur réalise en fait concrètement cela, mais a oublié le préfixe this. ?

Code:

---

1 2	if (this.age > ageLimite) throw(new IllegalStateException("Ce fromage ne doit vraiment plus valoir grand-chose, vous savez."));

---

ou bien même:

Code:

---

1 2	if (this.age > this.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...

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.

Jia,

Puisque agression (et pas aggression) tu veux :

Une solution pour ne plus avoir de problème : n'utilise pas Java. :yaisse2:

- D'une part, ce ne sont que des recommandations, pas une obligation.

Que je sache, il n'y a personne derrière toi avec un fusil pour t'obliger à utiliser leurs conventions.

- Et d'autre part, Sun étant le créateur du Java, ils ont quand même leur mot à dire, non ?

:dehors:

Histoire de polémiquer moi aussi :
1) j'utilise la première version. Pourquoi : parse que dès que je vois une fermante, il me suffit de tirer un tait vertical vers le haut pour connaitre de suite là quelle instruction/block elle appartient, ça m'évite de remonter une ligne au dessus de l'accolade ouvrante. Donc, sur ce point, c'est une question de point de vue personnel, étant un grand fainéant, cette méthode m'arrange.

2)
j'utilise TOUJOURS le this dans mes classes, la raison : c'est que par habitude et pour plus de clareté, dans tous mes setters, la variable passée en argument porte le même nom que la variable de classe que ça va affecter :

Code:

---

1 2 3 4

public void setAge(int age){ this.age=age; }

---

Si le this n'était pas employé, ça poserait problème car on aurais deux variable de même nom, d'ailleurs ça ne compilerait pas. La solution pour ne pas utiliser le this : nommé l'argument "a" par exemple, mais "a" ça veut dire quoi ? dans mon exemple c'est simple, mais que dire d'une méthode dont le nom possède plusieurs notions ( plusieurs majuscules en respectant la norme ) ?

moi, je suis plutôt partisan de cette solution là:

Code:

---

1 2 3

public void setAge(int age){ m_age=age; }

---

car ce qui pose problème, c'est que quand le développeur oublie le this et écrit cela:

Code:

---

1 2 3

public void rectifierAge(int age){ age = age }

---

cela compile très bien. Bien-sûr, l'erreur n'apparaît pas d'une manière aussi crue, aussi visible, mais son principe c'est qu'au moment où l'on suppose affecter la variable membre (où notre intention est de l'affecter...), on affecte en fait une variable locale.

this.age = age
pose le problème dès que l'on oublie this ou que par paresse on pense pouvoir s'en passer. Allez, sur les trois quarts des lignes sources des développeurs qui prétendent utiliser this, on ne le trouve en fait pas.

Le premier source, au pif, que je prends chez sourceforge: MemoryResourceLoader.java de XDoclet,

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26

public class MemoryResourceLoader extends ResourceLoader { private Map scripts = new HashMap();   public void init(ExtendedProperties extendedProperties) { }   public InputStream getResourceStream(String id) throws ResourceNotFoundException { String script = (String) scripts.get(id); if( script == null ) { throw new ResourceNotFoundException("No registered script for id = " + id); } return new ByteArrayInputStream(script.getBytes()); }   public boolean isSourceModified(Resource resource) { return false; }   public long getLastModified(Resource resource) { return Long.MAX_VALUE; }   public void addScript(String id, String script) { scripts.put(id,script); } }

---

au lieu de:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26

public class MemoryResourceLoader extends ResourceLoader { private Map scripts = new HashMap(); public void init(ExtendedProperties extendedProperties) { } public InputStream getResourceStream(String id) throws ResourceNotFoundException { String script = (String)this.scripts.get(id); if( script == null ) { throw new ResourceNotFoundException("No registered script for id = " + id); } return new ByteArrayInputStream(script.getBytes()); } public boolean isSourceModified(Resource resource) { return false; } public long getLastModified(Resource resource) { return Long.MAX_VALUE; } public void addScript(String id, String script) { this.scripts.put(id,script); } }

---

et je passe sur n'importe quel autre code source,
de n'importe quel projet, même ceux d'Apache ou de n'importe qui, tous ceux qui disent suivre cette norme le font imparfaitement.



m_age = age
ne posera jamais le problème, si toutes les variables membres sont préfixées par m_, impossible qu'il y ait ambiguïté.

Bonjour.

Citation:

---

Envoyé par grunt2000

age=age
:
:
cela compile très bien ...

---

Je ne sais pas quelle EDI et quel JDK tu utilises, mais chez moi, avec eclipse 3.2 et la JDK 6, il la considère comme une erreur !

Citation:

---

Envoyé par grunt2000

m_age = age;

---

Ah non, pitié, pas de ça en Java ! le tiret-bas est vraiment moche je trouve, et même déconseillé en Java. On l'utilise plutôt en C/C++, mais pas en Java où on utilise la différenciation de la casse : exemple mAge, monAge, etc., mais pas le m_age, mon_age, etc.

Bref, pour en avoir le coeur net, voici un lien vers les conventions officielles de nommage en Java.

Goa,

Pour le problème du this, il n'est tout de même pas difficile de donner un nom de paramètre différent du nom de la variable de la classe.

Vous vous créez vous-même les difficulté.

Citation:

---

Envoyé par iohack

j'utilise TOUJOURS le this dans mes classes, la raison : c'est que par habitude et pour plus de clareté, dans tous mes setters, la variable passée en argument porte le même nom que la variable de classe que ça va affecter :

Code:

---

public void setAge(int age){ this.age=age; }

---

Si le this n'était pas employé, ça poserait problème car on aurais deux variable de même nom, d'ailleurs ça ne compilerait pas. La solution pour ne pas utiliser le this : nommé l'argument "a" par exemple, mais "a" ça veut dire quoi ? dans mon exemple c'est simple, mais que dire d'une méthode dont le nom possède plusieurs notions ( plusieurs majuscules en respectant la norme ) ?

---

Tes choix de nom de variable/paramètres me semblent bien limités.

Tu peux choisir par exemple la solution de grunt2000, déjà bien répandue, ou mettre un préfixe/suffixe au nom du paramètre de la fonction, genre

Code:

---

public void setAge(int UN_age){ this.age=UN_age; }

---

etc...

L'imagination au pouvoir ! :lol:

Peut-être mais ta méthode est moins claire lorsque l'on génère la javadoc, faut penser au utilisateur/développeur suivants.
Si ( j'extrapole, hein c'est pas sérieux ) je vois UN_age, pour moi ça veut dire que j'en mets un au pif ? alors que si je vois age tout cours, là c'est précis, de plus dans "public void setAge(int age)" le terme est redondant ( ça va peut-être pas plaire à certains mais tant pis ), ça appuie la signifaction de la méthode. Faire un "public void setAge(int nombreDeCarottes)" c'est induire le futur utilisateur en erreur.

Bon j'arrête avec la polémique, c'est un débas sans fin. L'une et l'autre méthode on chacune aventages et inconvénients.

Pour ma part, j'utilise :

Code:

---

1 2 3 4 5

public void procedure() {   }

---

et

Code:

---

1 2 3 4 5

public constructeur(int age) { this.age = age ; }

---

Mais franchement, il existe 50 000 façon de noter. nous pourrions noter :

Code:

---

1 2 3

public constructeur(int agEs) { this.mAge = agEs ; }

---

le code n'est pas lisible mais :
- Il compile.
- Et qu'un autre programmeur puisse modifier le code.

Alors c'est le plus important je pense. Un chef d'entreprise ou l'utilisateur d'une application veut un code qui fonctionne peu importe la manière de coder.

J'en est fait l'expérience, le plus important quand tu programme est de mettre des commentaires. Si tu ne met pas de commentaires :
- Personne ne pourra modifier ton programme ou très lentement.
- Si tu reviens sur ton code ( un jour ) tu auras beaucoup de mal pour comprendre ton programme.

D'où l'intérêt d'une javadoc claire ;)