[Conventions]Méthodes et paramètres

Bonjour,

Je suis en train de me poser une question sur les conventions de codage. J'ai déja regardé dans le tutoriel sur developpez.com et rien n'en parle.

Ma question est la suivante, quand on appelle une méthode avec plusieurs paramètres (dison x(a,b,c,d,e) ), comme organise t'on les paramètres, faut-il les mettre sur plusieurs lignes ou alors on les mets seulement sur plusieurs lignes si on a pas la place en largeur pour tous les mettre les uns à cotés des autres.

Donc faut-il écrire :

Code:

---

z = x(a,b,c,d,e);

---

Ou alors plutôt écrire :

Code:

---

1 2 3 4 5 6

z = x( a, b, c, d, e);

---

Ou encore le premier paramètre sur la première ligne :

Code:

---

1 2 3 4 5

z = x(a, b, c, d, e);

---

Et pareil pour la déclaration de la méthode en question, faut il les écrire tous sur une ligne ou un par ligne ?

donc :

Code:

---

1 2 3

public Type x(Type a, Type b, Type c, Type d, Type e){   }

---

ou :

Code:

---

1 2 3 4 5 6 7 8

public Type x( Type a, Type b, Type c, Type d, Type e){   }

---

:merci:

P.S. S'il n'y a pas de conventions sur ce sujet, qu'est ce que vous vous employez comme façon de faire ?

Je ne sais pas s'il y a une convention sur le sujet, mais perso cela dépend du nombre de paramètres ou de leur type.
J'essaye de choisir la disposition que me paraît la plus clair (la moins bord****** :aie:) au premier coup d'oeil.

Code:

---

1 2 3 4 5 6 7 8 9

public void method(int a, int b) { // ... }   public void method( int i1, String s1, int i2, String s2, int i3, String s3) { // ... }

---

Pour résumer je fait plutôt du cas par cas.

Idem, je ne suis pas expert mais je ne crois pas qu'il existe une convention la dessus.
Personnellement j'utilise les 2 manieres (aussi bien pour les appels que pour les declarations), en fonction de la taille des parametres, histoire que le code reste lisible.

Code:

---

1 2 3 4

String result = method(parameter.substring(0, parameter.length() - 4), parameter.substring(parameter.length() - 4)); String result = method("java", ".exe");

---

Salut ;)

Citation:

---

Envoyé par wichtounet

on les mets seulement sur plusieurs lignes si on a pas la place en largeur pour tous les mettre les uns à cotés des autres.

---

Pour ma part, j'utilise plutôt cette méthode. Je rentre les paramètres sur la même ligne et s'il y en a trop, je vais à la ligne. Pourtant, dans la javadoc, je déclare chaque paramètre sur une ligne disctincte donc pas très cohérent ;)

Ensuite je préfèrerais ces formes

Code:

---

1 2 3 4 5 6 7

z = x( a, b, c, d, e );

---

Histoire d'encore mieux séparer. Ca me rappelle aussi le codage PHP de cette façon. Cela permet aussi de mieux commenter les paramètres pour les gens n'utilisant pas la javadoc.

Code:

---

1 2 3

public Type x(Type a, Type b, Type c, Type d, Type e){   }

---

Dans ce cas-là, j'essaie principalement de regrouper les paramètres par type. Par exemple, si j'attends 3 String et 2 Integer en paramètre, je vais ordonner de façon à pas mélanger les types, question d'esthétisme ;)

Voilà mon opinion et mes "mauvaises?" habitudes :D

Mon opinion c'est que j'en ais pas et que je laisse Jalopy tout faire à ma place

Sinok, assisté primaire

:mouarf: sinok terrible. M'enfin je rigole mais je vais me le prendre je pense :roll:

Sinon il y a les conventions de code de Sun (voir chapitre 4 "Indentation") suivies par défaut par Checkstyle.

Dans les conventions de Sun, il ne disent rien là-dessus. Par contre, dans les exemples avec Jalopy, il met chaque paramètre sur une ligne.

J'hésite un peu, mais je pense que je vais rester comme actuellement, avec tout sur une ligne et un retour à ligne s'il faut.

Moi je fais confiance à Ctrl+Shift+F :) (dans eclipse)

Bonjour

Je croyais que tu utilisais Eclipse Wichtounet ?

Comme l'a écris ®om

Citation:

---

Envoyé par ®om

Moi je fais confiance à Ctrl+Shift+F (dans eclipse)

---

Tu as même la possibilité de mettre les conventions de Sun comme formatteur (Preferences -> Java -> Code Style -> Formatter, de mémoire donc il peut avoir des variantes). Tu peux également configurer le formatteur à ta guise ;)

Oui, je l'utilise.

Mais pour configurer correctement le Formatter, faut bien connaître les conventions, non ? ;)

Perso,

Je trouve qu'une ligne doit correspondre au début d'une ligne lisible sans faire
mumuse avec les ascenceurs et finir parelilement :aie:

180 char max non ??

wichtounet t as l air d etre un putain de bon apprenti si j étais chef je t engagerais :mrgreen:

Citation:

---

Envoyé par wichtounet

Oui, je l'utilise.

Mais pour configurer correctement le Formatter, faut bien connaître les conventions, non ? ;)

---

Non ! :mouarf:
Je radote :

Préférences -> Java -> Code Style -> Formatter -> dans select a profile : "Java Conventions" (voilà pô besoin de les connaitre) ;)

Citation:

---

180 char max non ??

---

Arf c'est déjà énorme !!! Il faut au moins un écran 1936 pouces. Chez moi je ne vais pas plus loins que la colonne 80 ! Héritage du COBOL :aie:

Citation:

---

Envoyé par yann2

Non ! :mouarf:
Je radote :

Préférences -> Java -> Code Style -> Formatter -> dans select a profile : "Java Conventions" (voilà pô besoin de les connaitre) ;)

---

Bon, d'accord, si tu prends directement les conventions Java. Mais dans ce cas-là, pour ce qui est des appels de méthode, il met tout sur une ligne et retourne à la ligne si plus de place. Tandis que si tu prends l'autre formatteur par défaut (Eclipse Built-in je crois), il te met chaque paramètre sur une ligne différente.

Donc que faire :roll:

Citation:

---

Envoyé par yann2

Arf c'est déjà énorme !!! Il faut au moins un écran 1936 pouces. Chez moi je ne vais pas plus loins que la colonne 80 ! Héritage du COBOL :aie:

---

En effet, 180 c'es trop, mais je trouve que 80 c'est pas assez, je préfère du 100 ou un peu supérieur.

Bonjour

J'ai même fait la recherche pour toi (recherche de 'code convention' sur le site java.sun.com) :

http://java.sun.com/docs/codeconv/ht...nvTOC.doc.html

et avec ce lien tu peux voir que plusieurs variables d'une méthode sont sur la même ligne (il y a un saut uniquement si tu arrives à la colonne limite).

yann