Conventions de dénomination des variables en C ++

Question

Je viens d’un monde .NET et j’écris pour la première fois en C ++. Je me demande simplement quelles sont les conventions de dénomination préférées pour nommer les variables locales et les membres de structure.

Par exemple, le code hérité dont j'ai hérité en contient beaucoup:

struct MyStruct
{
   TCHAR           szMyChar[STRING_SIZE];
   bool            bMyBool;
   unsigned long   ulMyLong;
   void*           pMyPointer;
   MyObject**      ppMyObjects;
}

Venant d’un fond C #, j’ai été choqué de voir les variables avec la notation hongroise (je ne pouvais pas arrêter de rire du préfixe pp la première fois que je l’avais vue).

Je préférerais plutôt nommer mes variables de cette manière (bien que je ne sois pas sûr que la majuscule de la première lettre soit une bonne convention. J'ai déjà vu d'autres méthodes (voir les liens ci-dessous)):

struct MyStruct
{
   TCHAR           MyChar[STRING_SIZE];
   bool            MyBool;
   unsigned long   MyLong;
   void*           MyPointer;
   MyObject**      MyObjects;
}

Ma question: Est-ce toujours (le premier moyen) un moyen privilégié de nommer les variables en C ++?

Références:

http://geosoft.no/development/cppstyle.html

http://www.syntext.com/books/syntext-cpp- conventions.htm

http://ootips.org/hungarian-notation.html

Merci!

Answer 1

Ce type de notation hongroise est assez inutile et peut-être pire qu’inutile si vous devez changer le type de quelque chose. ( le type approprié de notation hongroise est une autre histoire. )

Je vous suggère d'utiliser ce que votre groupe fait. Si vous êtes la seule personne à travailler sur le programme, nommez-les de la manière qui vous convient le mieux.

Answer 2

Le plus important est d’être cohérent. Si vous travaillez avec une base de code héritée, attribuez à vos variables et fonctions uniformément la convention de dénomination du code hérité. Si vous écrivez un nouveau code qui ne fait qu’interfaçage avec un ancien code, utilisez votre convention de nommage dans le nouveau code, tout en restant cohérent avec vous-même.

Answer 3

Non. La "mauvaise notation hongroise" - surtout le pp pour double indirection - était logique pour les premiers compilateurs C où vous pouvez écrire

int * i = 17;
int j = ***i;

sans même un avertissement du compilateur (et cela pourrait même être un code valide sur le bon matériel ...).

La "vraie notation hongroise" (comme lié par la tête Geek) est OMI encore une option valide, mais pas nécessairement préféré. Une application C ++ moderne comporte généralement des dizaines ou des centaines de types, pour lesquels vous ne trouverez pas de préfixes appropriés.

Je l’utilise toujours localement dans quelques cas où je dois mélanger, par exemple. les variables entières et flottantes qui ont des noms très similaires ou même identiques dans le domaine problématique, par exemple

float fXmin, fXmax, fXpeak; // x values of range and where y=max
int   iXmin, iXMax, iXpeak; // respective indices in x axis vector

Toutefois, lors de la maintenance de codes hérités qui respectent certaines conventions de manière cohérente (même de manière approximative), vous devez vous en tenir à celles-ci, du moins dans les modules / unités de compilation existants à gérer.

Mon raisonnement: Les normes de codage ont pour objet de respecter le principe de la moindre surprise. L'utilisation constante d'un style est plus importante que le style que vous utilisez.

Answer 4

Qu'est-ce qu'il faut ne pas aimer et se moquer de " ppMyObjects " dans cet exemple, mis à part le fait qu'elle soit un peu moche? De toute façon, je n’ai pas d’opinions fortes, mais cela donne des informations utiles en un coup d’œil qui dit que " MyObjects " ne pas.

Answer 5

Je suis d'accord avec les autres réponses ici. Soit vous continuez à utiliser le style qui vous a été donné par souci de cohérence, soit vous créez une nouvelle convention qui convient à votre équipe. Il est important que l'équipe soit d'accord, car il est presque garanti que vous allez modifier les mêmes fichiers. Cela dit, certaines choses que j’ai trouvées très intuitives dans le passé:

Les variables de membre de classe / struct doivent ressortir - je les préfixe habituellement avec m_
Les variables globales doivent se démarquer - préfixe usuall avec g_
Les variables en général devraient commencer par des minuscules
Les noms de fonction en général devraient commencer par des majuscules
Les macros et éventuellement les énumérations devraient être en majuscules
Tous les noms doivent décrire ce que fait la fonction / variable et ne jamais décrire son type ou sa valeur.

Answer 6

Je suis moi-même un noteur hongrois, car je constate que le code est lisible et je préfère de loin le code auto-documenté aux commentaires et aux recherches.

Cela dit, je pense que vous pouvez défendre votre style préféré et une facilité de maintenance supplémentaire pour l’unité de votre équipe. Je n'achète pas l'argument de la cohérence au nom de la lisibilité uniforme du code, en particulier si la réduction de la lisibilité pour la cohérence ... ça n'a aucun sens. Bien s'entendre avec les gens avec qui vous travaillez peut toutefois valoir un peu plus de confusion sur les types qui examinent des variables.

Answer 7

La notation hongroise était courante chez les utilisateurs des API Win32 et MFC. Si vos prédécesseurs l'utilisaient, vous feriez probablement mieux de continuer à l'utiliser (même si ça craint). Le reste du monde C ++ n'a jamais eu cette convention de mort mentale, donc ne l'utilisez pas si vous utilisez autre chose que ces API.

Answer 8

Je pense que vous constaterez toujours que la plupart des magasins qui programment en Visual C ++ s'en tiennent à la notation hongroise ou au moins à une version allégée de celle-ci. Dans notre boutique, la moitié de notre application est du C ++ hérité avec une nouvelle couche C # brillante (avec une couche C ++ gérée au milieu). Notre code C ++ continue à utiliser la notation hongroise, mais notre code C # utilise la notation telle que celle que vous avez présentée. Je pense que c'est moche, mais c'est cohérent.

Je dis, utilisez ce que votre équipe souhaite pour votre projet. Mais si vous travaillez sur du code hérité ou si vous rejoignez une équipe, respectez le style présent pour assurer la cohérence.

Answer 9

Tout dépend de vos préférences personnelles. J'ai travaillé pour deux entreprises ayant des systèmes similaires, les vars membres étant nommés m_varName. Je n'ai jamais vu la notation hongroise utilisée au travail et je ne l'aime vraiment pas, mais encore une fois par préférence. Mon sentiment général est que les IDE devraient s'occuper de vous dire de quel type il s'agit, aussi longtemps que le nom est suffisamment descriptif de ce qu'il fait (m_color, m_shouldBeRenamed), alors c'est ok. L’autre chose que j’aime bien, c’est la différence entre variable de membre, variable locale et désignation constante. Il est donc facile de voir ce qui se passe dans une fonction et d’où viennent les vars. Membre: m_varName Const: c_varName local: nomVaru

Answer 10

Je préfère aussi CamelCase. En effet, la plupart du temps, j'ai vu des personnes utiliser CamelCase en C ++. Personnellement, je n'utilise aucun préfixe attendu pour les membres et interfaces privés / protégés:

class MyClass : public IMyInterface {
public:
    unsigned int PublicMember;
    MyClass() : PublicMember(1), _PrivateMember(0), _ProtectedMember(2) {}
    unsigned int PrivateMember() {
        return _PrivateMember * 1234; // some senseless calculation here
    }
protected:
    unsigned int _ProtectedMember;
private:
    unsigned int _PrivateMember;
};
// ...
MyClass My;
My.PublicMember = 12345678;

Pourquoi j'ai décidé d'omettre les préfixes des membres du public: Parce que les membres publics pouvaient être accédés directement comme dans les structures et ne pas entrer en conflit avec les noms privés. Au lieu d’utiliser des traits de soulignement, j’ai aussi vu des personnes utiliser la première lettre minuscule pour les membres.

struct IMyInterface {
    virtual void MyVirtualMethod() = 0;
};

Les interfaces ne contiennent par définition que des méthodes virtuelles pures qui doivent être implémentées ultérieurement. Cependant, dans la plupart des cas, je préfère les classes abstraites, mais ceci est une autre histoire.

struct IMyInterfaceAsAbstract abstract {
    virtual void MyVirtualMethod() = 0;
    virtual void MyImplementedMethod() {}
    unsigned int EvenAnPublicMember;
};

Consultez le Manuel standard de codage C ++ à haute intégrité pour plus d'inspiration.

Answer 11

Notre équipe utilise la convention de code Google C ++ :

Ceci est un exemple de nom de variable:

string table_name;  // OK - uses underscore.
string tablename;   // OK - all lowercase.

string tableName;   // Bad - mixed case.

Answer 12

Si vous utilisez CamelCase, la convention est de mettre en majuscule la première lettre. pour les classes structs et les noms de type non primitifs, et en minuscule la première lettre pour les membres de données. La capitalisation des méthodes a tendance à être un sac mélangé, mes méthodes ont tendance à être des verbes et sont déjà distinguées par des pairs alors je ne capitalise pas les méthodes.

Personnellement, je n'aime pas lire le code CamelCase et préfère les caractères de soulignement en minuscule. identifiants de données et de méthodes, types majuscules et réservation de sigles majuscules pour les acronymes et le cas rare où j'utilise une macro (en avertissant qu'il s'agit d'une MACRO).