Bonjour, je voudrais connaitre vos choix en matière de nomage de variable, je vais commencer un projet à plusieurs personne et j'aurais aimé mettre au point une certaine convention du choix des variables pour que le code soit par la suite plus facilement modifiable par n'importe quelle personne de l'équipe.
 
Il y a des choses évidentes comme ne pas commencer la variable par une majuscule, et lui donner un nom explice (ex: pas de String string Mais comment bien nomer une variable ?
 
Le developpement intègrera une partie SWING. Prenons l'exemple d'un JLabel qui affiche le nombre de page vous l'appeleriez plutot :

Un question également pour les variables de classe privées par exemple

Merci de vos avis  

Les conventions de nommage sur le projet sur lequel je travaille sont souples.
 
=> Conventions Sun, je n'y reviens pas
=> données membres préfixées par m_
=> paramètres des méthodes préfixés par p_
 
A l'usage c'est pas mal.
 
Le cas des JLabel Swing est particulier. Très souvent, un label va de pair avec un champ de saisie. Dans ce cas, je suffixe par Label le JLabel et par Input le champ de saisie. Parfois, je précise TextField, TextArea... plutôt que Input.

Pour le setMaChaine()  
 

 
Plus logique je trouve. On lui passe une chaine, pour mettre ma chaine
Enfin j'ai pas encore trop d'expérience avec ces conventions.

L'intérêt de ta méthode c'est surtout d'éviter de se tromper entre this.xxx et xxx, puisque dès la déclaration, ton paramètre à un nom différent du membre. Par ailleurs, this devient superflu.

d'autres avis de javateu ?

le coup des '_' est une habitude fort répandue qui est d'ailleur gérée par la majorité des IDE.  
Perso je l'aime pas trop... elle va quand même un peu à l'encontre des conventions java ...
 
moi je code à coup de 'this' pour les données membres. j'aime bien parce que eclipse me fait la completion automatique directement après avoir tapé "this." ... et je trouve ca bien lisible ... et ca va bien quand tu fais des inner classes et que tu as besoin de préfixer par le nom de la outerclasse : ca reste la même syntaxe : OuterClasse.this.member

 
et quand tu swing tu nomes comment ?

up

je swing pas mais qu'est ce que ca peut changer ?

pareil que benou, et un peu comme cherytree :  
 
 - je préfixe systematiquement par this mes variables memebre...pour moi java fourni un moyen de les différencier, je vois pas l'intéret d'en utiliser un autre...en plus, ca offre la complétion sous tous les IDE...
- mes paramètres ont tjs le meme nom que la variable memebre :  

 
pour swing, je fais comme cherytree sur le principe
 
par ex :  

 
de sorte que je sais tjs partout dans mon code que pour un attribut donné, le label sera attributLabel, et sa valeur sera attributValue

... vous devriez tous éviter de mélanger le français et l'anglais, si vous voulez mon avis.. à fortiori à l'interieur d'un meme nom de variable (nomValue, pitié )

Pour ma part, ce serait comme ça :

Y'a que pour les contrôles que je met vaguement le type. Aussi, jamais de variables ou de fonctions en français. Je code 100% en anglais (sinon bonjour le merdier entre français et anglais, on s'y retrouve plus).
 
Et je plussoie pour l'utilisation du this. Jamais de m_bidule, toujours this.bidule.
 
Enfin pour un setMaChaine :

J'utilise toujours le même truc : On veut définir 'pouet' grâce à 'setPouet', donc pour moi c'est logique d'avoir comme nom de paramètre 'pouet'...

 
pour le nom des champs :
 

 
 
je sais, ct pour l'exemple...je code toujours en anglais aussi...c probablement la pratique de dev la plus répandue de partout : c'est dans toutes les normes de dev

Pas chez nous, on nous demande explicitement du Français. En même temps va traduire un élément de règlementation FR en langue UK. Pas toujours très malin, toujours très hideux par contre.

T'entends quoi par élément de réglementation FR ?

C'est du vocabulaire métier spécifique à son projet, je présume.

pendant qu'on y est : les sauts de ligne, vous en mettez où ?
 
je trouve que mon code est trop compact...g essayé aujourd'hui de toujours sauter une ligne avant un if/while, etc...ca aère ca me plait...mais y'a surement mieux

j'en met ou ça a du sens

 
Je déteste le code trop compact.

ben justement : c où ces endroits où ca a du sens pour toi ?
 
edit : whatde : ok...en gros, par méthode : le bloc de variables locale, et un espace entre chaque bloc de code genre try, if, etc...

Mais bon tout le monde n'aime pas    
Ca n'empêche que je vois souvent pire  

ben ça dépend ce que le bout de code dont on parle fait

ben tiens, tant qu'on arrive au coding style, les commentaires:
http://www.theserverside.com/news/ [...] 5_05-click
j'ai pas lu l'article lié à ce thread, mais j'adhere au résumé et à 200% au premier post du thread

intéressant...c vrai que son exemple sur l'auth est parlant...
 
c vrai que j'ai tendance à écrire des méthodes trop longues...

Présicément.

pour donner mon opinion, je suis aussi partisan du this et donc pas ajouter des méta-infos dans le nom d'une variable/méthode. Je relègue le boulot à l'IDE qui doit se débrouiller me dire qui une méthode/un attribut est privé/public/autre et autre truc du genre.
 
Pour ce qui est des sauts de ligne dans une méthodes, j'ai pas vraiment de méthode. En général, je saute une ligne après mes déclarations de variables locales (comme WhatDe). Pour ce qui est des sauts de lignes entre blocs, j'en mets entre des blocs assez conséquents (pas pour des blocs de moins de 5 lignes) ou entre des ensembles de blocs fonctionnellement différents.
Genre aprés avoir initialiser une connexion, ou une initialisation.
J'évite d'aérer systématiquement car ça limite ensuite la visibilité.
 
Et souvent, au lieu de sauter une ligne, j'ajoute une ligne de commentaire qui annonce le prochain bloc de ligne. Ça segmente visuellement comme un saut de ligne, mais en plus ça ajoute de l'info ... Mais bon, encore une fois, c'est pas systématique

J'en rajoute une petite couche. Concernant mon projet actuel :
-> champs d'une classe : un nom explicite
-> variables locales : commencent par "l_"
-> paramètres d'une fonction : commencent par "a_"
-> itérateurs : commencent par "it_"
 
Entre autres...

Moi j'aime pas les underscores dans les variables... J'en met que en PHP parce que c'est la norme, et en VB.NET devant les variables membres qui ont une propriété à leur nom, genre :

 
encore une bonne raison pour pas le faire, CQFD...
 
sinon ok si on code sous VI c intéressant de savoir si c du local, membre, etc...mais avec un ide je vois pas l'intéret...y'a l'outline, le mouseover, tt une mine d'info

Salut,
 
de mon coté les variables suivent la rêgle suivante :  
 
m_ pour les données membre
l_ pour les variables locales
a_ pour les attributs de méthodes
 
Ensuite le nom de la variable elle même ne contient pas d'underscore, des majuscules permettent de faciliter la lecture ex : m_MaDonneeMembre a_MonParametre l_MaVariableLocale.
 
De plus, les outils font la complétion automatique donc tout ce qui est i, m, a, prout ou pouet sont à proscrire. On demande des variables ayant un nom explicite même si ils sont un poil long.
 
Voilà tout ...
 
@+

keskidi

pour en revenir à ce que j'ai pondu là :
http://forum.hardware.fr/forum2.ph [...] 6#t1097496
 
au départ, j'avais mis tout le code de disableAddElementActionForFourSeconds() à son point d'utilisation, mais en le sortant, d'une part j'évite d'avoir à mettre un commentaire sur ce qu'on fait lors du clic sur le bouton, d'autre part, j'évite de noyer le lecteur sur comment je le fait. S'il veut le savoir, ctrl+clic et hop, il le sait, mais on l'agresse pas avec des détails.

ca m'arrive de mettre un underscore dans un cas précis : l'utilisation d'une variable temporaire qui n'est utilisée que très très localement.
 
ex :  
 
String str_page = request.getParameter("page" );
int page = Integer.parseInt(str_page);
 
ca me permet de savoir qu'elle n'a pas à être utilisée par la suite

ben c'est bien, mais les conventions d'écriture en général c'est pour faciliter le travail à plusieurs

j'aurais preque été déçu que tu critiques pas tiens ...

tu la mets "final", comme ça t'es sur de pas avoir de surprises

je fais rarement, ca ... manque d'habitude ...

ben stadir que bon, oui stu veux, jpeux etre aussi constructif que toi:
moi des fois quand j'ai une variable temporaire qui ne sert à rien, je l'appelle "zoubida" ou "trilili".
comme ça, je sais que si je reviens sur ce code plus tard, ça me sautera assez aux yeux pour que je voie que je ne dois pas utiliser cette variable.
 
 
 
 
    ché pas quoi

de toutes façons ça résout pas grand'chose pour les objets :

 
par contre, pour les types primitifs, oui.