[Débat] convention de nommage

Bonjour tout le monde,

je dois faire une convention de nommage, et j'avoue que jusqu'ici, je n'ai travaillé que sur des projet déjà commencé, je me suis donc toujours contenté d'appliquer les conventions qui existaient (et si elles n'existaient pas, d'appliquer les règles officieuses du code existant).

Je me pose donc tout un tas de questions, et les réponses que je trouve sur le net ne me satisfont pas. Et puis c'est toujours agréable de discuter avec vous ;)

Donc voici mes questions:
1 -> Il semble que les noms de fonctions qui commencent par une majuscule ne soient plus "à la mode". Y a-t-il une raison particulière à cela? (je demande ça parce que moi j'aime bien).

2 -> Quel nommage vous parait le meilleur pour les fonctions:

• NomDeFonction()
• nomDeFontion()
• nom_de_fonction()
• autre?

3 -> Pour les variables membres, quelle forme pensez-vous être la meilleure:

• m_VariableMembre
• m_variable_membre
• VariableMembre_
• variableMembre_
• autre?

4 -> Pensez-vous qu'il soit utile/important de différencier les variables passées en paramètre des variables locales à une fonction?
Par exemple:

Code:

---

1 2 3 4 5

void UneFonction(int p_unInt, std::string p_uneChaine) { std::string uneChaine = p_uneChaine; //... }

---

:merci:

Sur l'indication dans le nom d'informations relatives au stockage d'une entité, c'est un vaste débat initié à l'age des cavernes des langages par l'affreux cosmonaute hongrois... Pour moi, c'est absolument NON, mais on n'a pas toujours le choix.
Par contre, pour ce qui est de la typographie, j'ai changé l'année dernière après avoir été sensibilisé au problème par un projet utilisant les conventions suivantes:

Citation:

---

Envoyé par JOINT STRIKE FIGHTER AIR VEHICLE C++ CODING STANDARDS

4.9.1 Naming Identifiers
The choice of identifier names should:
• Suggest the usage of the identifier.
• Consist of a descriptive name that is short yet meaningful.
• Be long enough to avoid name conflicts, but not excessive in length.
• Include abbreviations that are generally accepted.
Note: In general, the above guidelines should be followed. However, conventional usage of simple identifiers (i, x, y, p, etc.) in small scopes can lead to cleaner code and will therefore be permitted.
Additionally, the term ‘word’ in the following naming convention rules may be used to refer to a word, an acronym, an abbreviation, or a number.
AV Rule 45
All words in an identifier will be separated by the ‘_’ character.
Rationale: Readability and Style.
AV Rule 46 (MISRA Rule 11, Revised)
User-specified identifiers (internal and external) will not rely on significance of more than 64 characters.
Note: The C++ standard suggests that a minimum of 1,024 characters will be significant. [10]
AV Rule 47
Identifiers will not begin with the underscore character ‘_’.
Rationale: ‘_’ is often used as the first character in the name of library functions (e.g. _main, _exit, etc.) In order to avoid name collisions, identifiers should not begin with ‘_’.
Doc. No. 2RDU00001 Rev C
Date: December 2005
25
AV Rule 48
Identifiers will not differ by:
• Only a mixture of case
• The presence/absence of the underscore character
• The interchange of the letter ‘O’, with the number ‘0’ or the letter ‘D’
• The interchange of the letter ‘I’, with the number ‘1’ or the letter ‘l’
• The interchange of the letter ‘S’ with the number ‘5’
• The interchange of the letter ‘Z’ with the number 2
• The interchange of the letter ‘n’ with the letter ‘h’.
Rationale: Readability.
AV Rule 49
All acronyms in an identifier will be composed of uppercase letters.
Note: An acronym will always be in upper case, even if the acronym is located in a portion of an identifier that is specified to be lower case by other rules.
Rationale: Readability.
4.9.1.1 Naming Classes, Structures, Enumerated types and typedefs
AV Rule 50
The first word of the name of a class, structure, namespace, enumeration, or type created with typedef will begin with an uppercase letter. All others letters will be lowercase.
Rationale: Style.
Example:
class Diagonal_matrix { … }; // Only first letter is capitalized;
enum RGB_colors {red, green, blue}; // RGB is an acronym so all letters are un upper case
Exception: The first letter of a typedef name may be in lowercase in order to conform to a standard library interface or when used as a replacement for fundamental types (see AV Rule 209).
typename C::value_type s=0; // value_type of container C begins with a lower case
//letter in conformance with standard library typedefs
Doc. No. 2RDU00001 Rev C
Date: December 2005
26
4.9.1.2 Naming Functions, Variables and Parameters
AV Rule 51
All letters contained in function and variable names will be composed entirely of lowercase letters.
Rationale: Style.
Example:
class Example_class_name
{
public:
uint16 example_function_name (void);
private:
uint16 example_variable_name;
};
4.9.1.3 Naming Constants and Enumerators
AV Rule 52
Identifiers for constant and enumerator values shall be lowercase.
Example:
const uint16 max_pressure = 100;
enum Switch_position {up, down};
Rationale: Although it is an accepted convention to use uppercase letters for constants and enumerators, it is possible for third party libraries to replace constant/enumerator names as part of the macro substitution process (macros are also typically represented with uppercase letters).

---

Je sais, c'est illisible, mais c'est un extrait d'un document de 150+ pages. Voir les paragraphes 4.9.1

Je venais de près de 25 ans de notation CommeCeci et CommeCelaMemePourDesNomsTresLongs, et j'ai pu noter une amélioration telle que je me suis mis des claques pour ne pas avoir changé plus tôt.

1. Aucune idée...
2. Windows et .Net utilisent et préconisent NomDeFonction() et NomDeFonctionMembre(), java préconise nomDeMéthode().
3. Je préconise m_VariableMembre, mais .Net préconise variableMembre, au mépris des variables locales. Mais .Net utilise peu de variables et préconise PropriétéMembre.
4. Pas vraiment. Je ne le fais pas, en tout cas.

Et quant à la notation hongroise, je suis partisan de la Apps Hungarian et de ce que j'appelle la Pointers Hungarian, mais j'ai tendance à dériver malgré moi vers la Systems Hungarian par moment...

lol
salut,


1 -> +1
2 -> NomDeFonction()
3 -> m_VariableMembre
4 -> non

Bon courage.

1 -> je pense pour bien différencier les types ( class, enum, struct..) du reste, les premiers étant souvent écrits avec une majuscule .

2 -> c'est pas très important, faut juste rester cohérent

3 -> ce qui te fait plaisir

4 -> non

1- parce que souvent MajMajMaj désigne un nom de classe et autres types ?

2- maPreferee(), sinon_la_facon_de_la_sl()

3- m_maPreferee,
Ceci dit, le post-fixage par '_' est intéressant

4- Jusqu'à présent, je ne pratiquais rien de particulier.
Dans la norme imposée par un client, cEstFaitAinsi_. Ce qui est très perturbant quand ailleurs c'est réservé aux vairables membre (notament dans des bibliothèques externes employées (ACE)). Et puis, on s'y fait.


PS: La notation hongroise originale traite de catégorie (kind), pas de type. Même si aujourd'hui tout le monde est persuadé du contraire. Cf l'article sur le site JoelOnSoftware.

1) Classe, Namespace, methode
2) methodeAvecDesIndications
3) m_petiteLettreAuDebut, static s_uneVariableDeClasseStatique, g_uneVariableGlobale (en dehors de classe).
4) aucune differenciation, car le "scope" des parametres comme des variables locales devraient etre sous tes yeux, 10 lignes plus haut.

Salut,

Y'a ça qui donne une bonne base : http://geosoft.no/development/cppstyle.html

Sinon pour répondre aux questions :
1. parce que ça prête à confusion avec les noms de classes (et pour faire comme en Java)
2. nomDeFonction()
3. maVariable_
4. non, si une méthode/fonction ne fait pas plus de quelques lignes le problème ne se pose pas

MAT.

Moi j'utilise celles-ci, mon projet é tro stylé mtn :

Code:

---

1 2	m4_v4r14bl3_m3mbr3; m4F0nc710n();

---

1. parce que cette syntaxe est disponible et différente d'un nom de type. Mais je trouve couramment du code avec une majuscule au début.
2. nomDeFonction (souvent, d'ailleurs, un verbe plus qu'un nom... J'ai beaucoup de mal avec les _ qui pour moi coupent le rythme de lecture)
3. autre : J'utilise myMemberVariable (je ne programme pas en français, où le choix du sexe poserait peut-être problème). Raison principale par rapport aux alternatives proposées : Ca peut se lire aisément mentalement ou à voix haute quand on discute du code avec un collègue.
4. non

Moi je différencierais trois grands styles majeurs:

- La norme de nommage du C++ (adaptée du C), utilisée par la stl puis par boost, puis par tous les développeurs qui adulent boost. Le fonctionnement est on ne peut plus simple: tout est écrit en minuscules, les mots sont séparés par des underscores. Pour ceux qui utilisent des accesseurs il y a deux écoles: les get_xxx(), set_xxx() ainsi que les xxx() tout court, la deuxième solution obligeant parfois à déclarer les champs private précédés d'un underscore pour ne pas créer de conflit, ce qui fait que certains développeurs déclarent systématiquement leurs champs private avec un underscore (quoi que selon mon point de vue, tout ce qui est variable locale ou champ private peut être déclaré en utilisant n'importe quel nom, seul les l'interface publique doit se conformer obligatoirement à une norme de nommage).
Bien que je l'utilise (en C++ uniquement), force est de constater qu'elle n'est pas géniale. Elle suffit en C++ de par sa syntaxe qui permet (presque) toujours de connaitre la nature d'un indentifiant mais elle n'exploite pas du tout les majuscules ce qui est dommage pour la lisibilité je trouve. Elle n'est pas non plus appropriée à d'autre langages comme le Java (imaginez "xxx.yyy()", question: xxx est un objet ou une classe?).

- La norme de nommage du Java. Les classes commencent par une majuscule, tout le reste par une minuscule. Pour séparer les mots dans un identifiant, on fait commencer le deuxième, troisième, etc par une majuscule. On n'utilise jamais d'underscore. Les accesseurs utilisent une seule syntaxe très stricte: getXxx(), setXxx() (pour des raisons techniques en Java, appliquée à un autre langage ce n'est plus une nécessité mais par convention...). Ma préférée, elle est très simple à taper, à lire, et contrairement aux deux autres syntaxes majeures que je connais elle permet au moins de différencier quelque chose (les classes).

- La norme "C# style". Comme celle du Java sauf que tout commence par une majuscule, plus seulement les classes. Que voulez vous que je vous dises? J'ai beau me creuser la tête, je ne parviens pas à lui trouver le moindre avantage. Plus de majuscules -> plus difficile à taper. Plus aucune différence entre les classes et le reste -> plus difficile à lire. Pour moi c'est la plus mauvaise.

Une petite réflexion sur la notation hongroise: je crois qu'on en a tous entendu parler mais je n'ai jamais vu ça utilisé dans un projet. C'est probablement qu'avec les évolutions des ide, la coloration syntaxique et l'auto-completion ce n'est plus d'actualité.

Pour résumer je dirais qu'en C++ il vaut mieux utiliser la norme mise en place par la stl et boost (pour la bonne et simple raison qu'on a déja très très peu de normes en C++, alors autant respecter le peu qui sont disponibles) mais que la norme de nommage du Java n'est pas une mauvaise idée non plus.

Pour répondre à la question 4 de rud: bof, non, comme je l'ai dit plus haut je ne pense pas qu'il soit même nécessaire d'utiliser une quelconque norme à l'intérieur d'une fonction.

Pour revenir sur la notation hongroise (et les ulcères qu'elle provoque chez certains...), il y a un bon article à lire sur Joel On Software "Making Wrong Code Look Wrong".

Spolsky explique en outre pourquoi la notation Hongroise qui s'est répandue (Systems Hungarian) est inutile, mais que celle de départ (Apps Hungarian) était finalement pas si mal.

Perso, j'ai tendance à utiliser une notation hongroise "minimaliste":

• pMonPointeur, parce qu'un pointeur ne s'utilise pas comme les autres variable que maintenant je ne peux plus écrire "someVariable->someThing()" sans que cela génère angoisses et bouffées de panique.
• szMaVieilleChaineEnC parce que j'utilise principalement les std::string(), et que cela me fournit un signal très clair que je suis en train de régresser vers le monde des chaînes en C et que les règles changent.

Carl

Et je ne suis pas d'accord avec son article. Plutôt que de se baser sur une convention de nommage, il y a moyen en C++ d'utiliser le système de types pour que le compilateur attrape toutes les erreurs, sans exception. Ca me semble bien plus sûr quand même.

C'est comme ta convention sur les pointeurs : Est-ce si grave, sachant que le compilateur va te faire une erreur si tu utilises -> sur une variable où ce n'est pas possible ?

Citation:

---

Envoyé par JolyLoic

C'est comme ta convention sur les pointeurs : Est-ce si grave, sachant que le compilateur va te faire une erreur si tu utilises -> sur une variable où ce n'est pas possible ?

---

Non, ce n'est pas si grave mais je partage son avis sur les pointeurs. Ca facilite la lecture et permet au passage de faire la distinction entre la variable et le pointeur.

Ok, mon argument était mal choisi. C'est un gain dans la mesure où, comme c'est dit et répété partout sur le forum et ailleurs, le code est plus souvent lu par des humains qu'écrit ou compilé.

Au boulot nous faisons des revues de codes pour toutes les livraisons de code qui vont sur des branches un peu critiques (comme les bugfix par exemple, ou juste avant une release), et nous avons même un système de revue de code en ligne pour les cas où le collègue le mieux désigné pour vérifier le code n'est pas disponible.

Pas de compilateur à l'horizon à ce moment-là, et les petites conventions comme cela permettent de faciliter la vie de tout le monde. Et si on devait introduire de petites classes pour chaque sémantique différente d'une chaîne de caractères, on alourdit considérablement la quantité de connaissances que doit avoir le lecteur pour comprendre tout ce qui se passe à l'écran.

Carl

PS. Note aussi que l'article est valable pour des langages moins typés que le C++. J'utilise des conventions similaires en Python, par exemple.

Vous faites des revues de code sur du code qui ne compile pas?

Mais bien sûr, Jean-Marc, c'est pour cela que notre produit cartonne! ;-)

Plus sérieusement, bien sûr que non. Ce que je veux dire, c'est que le lecteur n'a pas l'excuse d'avoir un compilateur sous la main.

Entre ces deux affectations, laquelle fournit le plus d'information?

Code:

---

trackIndex = 0;

---

Code:

---

pTrackIndex = 0;

---

Si "trackIndex" et "pTrackIndex" sont tous deux de type "int*", la seconde version me paraît donner plus d'informations sur l'intention de l'instruction.

Citation:

---

Envoyé par JolyLoic

Et je ne suis pas d'accord avec son article. Plutôt que de se baser sur une convention de nommage, il y a moyen en C++ d'utiliser le système de types pour que le compilateur attrape toutes les erreurs, sans exception. Ca me semble bien plus sûr quand même.

---

C'est vrai pour le C++ (dans une certaine mesure), mais son article ne traite pas de C++, mais de la notation hongroise :P

"Dans une certaine mesure" parce que l'on est limité par les frameworks et bibliothèques que l'on utilise. Rares (inexistants?) seront ceux et celles qui ont un type Ligne et un autre type Colonne. Oui, en C++ c'est possible, mais dans la pratique personne ne pousse le vice jusque là. J'en arrive à penser que c'est un miracle quand il y a une classe Date et une classe Duree.

On pourrait mettre une règle de qualité qui stipule "une classe par type" (Ligne et colone sont bien deux types (au sens kind) de données différentes) de données manipulées. Mais comme pour le nombre de lignes dans les fonctions, il y aurait aussitôt une levée de boucliers. Alors on leur pond des (parfois mauvaises) règles de contournement : notation hongroise dans un cas, SESE (au sens large: return/break/continue) dans l'autre.

Citation:

---

Envoyé par 5hdumatin

Plus sérieusement, bien sûr que non. Ce que je veux dire, c'est que le lecteur n'a pas l'excuse d'avoir un compilateur sous la main.

---

Je ne vois pas alors pourquoi le fait que vous n'avez pas de compilateur au moment des revues de code est pertinent.

Citation:

---

Entre ces deux affectations, laquelle fournit le plus d'information?

Code:

---

trackIndex = 0;

---

Code:

---

pTrackIndex = 0;

---

Si "trackIndex" et "pTrackIndex" sont tous deux de type "int*", la seconde version me paraît donner plus d'informations sur l'intention de l'instruction.

---

Si quelqu'un donne pour nom "index" à un pointeur sur int, je fais une remarque quand on passe sur la déclaration de cette variable! Si l'objectif est de permettre une certaine compréhension quand le reste du nom est mal choisi, je m'incline.

Citation:

---

Envoyé par Luc Hermitte

On pourrait mettre une règle de qualité qui stipule "une classe par type" (Ligne et colone sont bien deux types (au sens kind) de
données différentes) de données manipulées.

---

Maintenant, transpose.

Même en Ada je n'introduisais pas des nouveaux types pour cela (des sous-types, oui, mais l'effet est différent, ça n'empèche pas une erreur).