IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

C++ Discussion :

[Débat] convention de nommage


Sujet :

C++

Vue hybride

Message précédent Message précédent   Message suivant Message suivant
  1. #1
    r0d
    r0d est déconnecté
    Membre expérimenté

    Homme Profil pro
    Développeur informatique
    Inscrit en
    Août 2004
    Messages
    4 290
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Ain (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : Août 2004
    Messages : 4 290
    Billets dans le blog
    2
    Par défaut [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 : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    void UneFonction(int p_unInt, std::string p_uneChaine)
    {
        std::string uneChaine = p_uneChaine;
    //...
    }

  2. #2
    Membre chevronné

    Inscrit en
    Août 2007
    Messages
    300
    Détails du profil
    Informations forums :
    Inscription : Août 2007
    Messages : 300
    Par défaut
    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.

  3. #3
    Expert éminent
    Avatar de Médinoc
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Septembre 2005
    Messages
    27 395
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 41
    Localisation : France

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Septembre 2005
    Messages : 27 395
    Par défaut
    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...
    SVP, pas de questions techniques par MP. Surtout si je ne vous ai jamais parlé avant.

    "Aw, come on, who would be so stupid as to insert a cast to make an error go away without actually fixing the error?"
    Apparently everyone.
    -- Raymond Chen.
    Traduction obligatoire: "Oh, voyons, qui serait assez stupide pour mettre un cast pour faire disparaitre un message d'erreur sans vraiment corriger l'erreur?" - Apparemment, tout le monde. -- Raymond Chen.

  4. #4
    yan
    yan est déconnecté
    Rédacteur
    Avatar de yan
    Homme Profil pro
    Ingénieur expert
    Inscrit en
    Mars 2004
    Messages
    10 035
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 43
    Localisation : France, Ille et Vilaine (Bretagne)

    Informations professionnelles :
    Activité : Ingénieur expert
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : Mars 2004
    Messages : 10 035
    Par défaut
    lol
    salut,


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

    Bon courage.

  5. #5
    Membre émérite
    Profil pro
    Inscrit en
    Mai 2006
    Messages
    780
    Détails du profil
    Informations personnelles :
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations forums :
    Inscription : Mai 2006
    Messages : 780
    Par défaut
    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

  6. #6
    Expert confirmé
    Avatar de Luc Hermitte
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Août 2003
    Messages
    5 296
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : Août 2003
    Messages : 5 296
    Par défaut
    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.
    Blog|FAQ C++|FAQ fclc++|FAQ Comeau|FAQ C++lite|FAQ BS|Bons livres sur le C++
    Les MP ne sont pas une hotline. Je ne réponds à aucune question technique par le biais de ce média. Et de toutes façons, ma BAL sur dvpz est pleine...

  7. #7
    screetch
    Invité(e)
    Par défaut
    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.

  8. #8
    Membre Expert

    Profil pro
    Inscrit en
    Juin 2006
    Messages
    1 294
    Détails du profil
    Informations personnelles :
    Localisation : Royaume-Uni

    Informations forums :
    Inscription : Juin 2006
    Messages : 1 294
    Par défaut
    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.

  9. #9
    Membre éprouvé
    Avatar de NiamorH
    Inscrit en
    Juin 2002
    Messages
    1 309
    Détails du profil
    Informations forums :
    Inscription : Juin 2002
    Messages : 1 309
    Par défaut
    Moi j'utilise celles-ci, mon projet é tro stylé mtn :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    m4_v4r14bl3_m3mbr3;
    m4F0nc710n();

  10. #10
    Rédacteur/Modérateur
    Avatar de JolyLoic
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Août 2004
    Messages
    5 463
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 50
    Localisation : France, Yvelines (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Août 2004
    Messages : 5 463
    Par défaut
    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
    Ma session aux Microsoft TechDays 2013 : Développer en natif avec C++11.
    Celle des Microsoft TechDays 2014 : Bonnes pratiques pour apprivoiser le C++11 avec Visual C++
    Et celle des Microsoft TechDays 2015 : Visual C++ 2015 : voyage à la découverte d'un nouveau monde
    Je donne des formations au C++ en entreprise, n'hésitez pas à me contacter.

  11. #11
    Membre confirmé Avatar de raoulchatigre
    Profil pro
    Inscrit en
    Mars 2004
    Messages
    99
    Détails du profil
    Informations personnelles :
    Âge : 42
    Localisation : France, Bas Rhin (Alsace)

    Informations forums :
    Inscription : Mars 2004
    Messages : 99
    Par défaut
    Bon je n'ai pas encore lu le thread en entier mais...

    mes 2 cents :

    Lorsque j'ai intégré ma boite, j'ai du me faire à une convention "maison" qui ressemble à la hongroise, mais en encore plus pervers :

    i_Integer
    l_Long
    sz_CharEtoile
    str_String
    o_Object

    o_mMemberObject
    i_gGlobal
    sz_fFunctionThatReturnsACharEtoile
    l_pPointeurSurLong

    Bon, je vulgarise le langage mais vous avez compris l'idée.
    Et bien sachez que je n'approuve pas du tout ces conventions
    Bon je n'ai pas le choix je fais avec mais ca m'énerve passablement.

    J'ai également lu dans un bouquin "Standard de programmation en C++" [Herb Sutter & Andrei Alexandrescu] que la convention que l'on choisi ne doit pas être trop contraignante car on finit toujours par la transgresser à un moment ou à un autre. Et je trouve cette remarque assez vrai.

  12. #12
    Membre émérite
    Profil pro
    Inscrit en
    Mai 2006
    Messages
    780
    Détails du profil
    Informations personnelles :
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations forums :
    Inscription : Mai 2006
    Messages : 780
    Par défaut
    oui, dans ma boite avec la convention de nommage on se retrouve avec:

    - des codes qui remplacent le nom des classes ( genre GLSF90 )
    résultat: c'est incompréhensible même avec un diagramme

    - une notation pseudo-hongroise horrible avec genre un préfixe cls ou cl pour..... classe!! ( même en Java ou C#!! )

    voilà un exemple véridique:

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    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
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
     
    /*     Method TGOCW030Convert :: TYP1ToTYP2
     *
     *     Constant conversion.
     *
     *		@author /(protegeons son anonymat)\ 18/07/2007
     *
     *		@param	strTYP1
     *		@param	strTYP2
     *
     *		@return	See description.
     */
    void TGOCW030Convert :: TYP1ToTYP2( const TMaboiteString &strTYP1, TMaboiteString &strTYP2 )
    {
       const int   iTYP1_CN16I = 6;
       const char  *apszTYP1_CN16I[ iTYP1_CN16I ] =
       {
           TYP1_CNES1
           , TYP1_CNES2
           , TYP1_CN16AE
           , TYP1_CN16AR
           , TYP1_CN16A8
           , TYP1_CN16A9
       };
     
       strTYP2 = "";
     
       for( int i = 0; i < iTYP1_CN16I; i++ )
       {
           if( apszTYP1_CN16I[ i ] == strTYP1.c_str() )
           {
              strTYP2 = TYP1_CN16I;
     
              break;
           }
       }
    }
    C'est le jeu des 46 erreurs. Remplacer ça par en 3 lignes compréhensibles. Bien sûr tout ce qui est en majuscule est un #define dans un long fichier de constante.


    Voilà, heureusement là où je suis je n'ai pas à travailler avec ces horreurs et j'utilise la norme que je veux, je ne suis pas le département informatique classique.

    Mais on a beau leur répeter qu'ils vont droit dans le mur, ils continuent. C'est quand même dingue de ne pas vouloir ouvrir un bouquin correct de C++. C'est pas faute de leur avoir indiqué ou rédigé un résumé de 15 pages.

  13. #13
    Membre confirmé Avatar de raoulchatigre
    Profil pro
    Inscrit en
    Mars 2004
    Messages
    99
    Détails du profil
    Informations personnelles :
    Âge : 42
    Localisation : France, Bas Rhin (Alsace)

    Informations forums :
    Inscription : Mars 2004
    Messages : 99
    Par défaut
    Mon dieu, et moi qui trouvait nos sources incompréhensibles !
    Là c'est du magnifique !

    Ps : j'ai aussi tous mes sources qui commencent par cl_MaClasse.hh, cl_MaClasse.cc
    c'est d'un utile !

    Pour revenir sur mon discours : je cite donc "Standard de programmation en C++" [Herb Sutter & Andrei Alexandrescu]
    Article 0. Laissez de côté les petites choses (ou: sachez ce qu'il ne faut pas standardiser)
    Dites uniquement le nécessaire, n'imposez pas vos préférences personelles ni des pratiques obsolètes.
    Les questions, qui ne concernent que le gout personnel et n'affectent en rien l'exactitude ou la lisibilité, n'ont pas leur place dans un standard de programmation. Tout programmeur professionnel peut aisément lire et écrire un code dont la mise en forme est légèrement différentedu format habituel. [...]
    Ne spécifiez pas la taille de l'indentation, mais appliquez-la pour faire ressortir la structure : utilisez le nombre d'espaces que vous voulez pour indenter, mais soyez cohérent au moins à l'interieur de chaque fichier.
    [...]
    Ne légiférez pas trop le nommage mais utilisez une convention de nommage cohérente. il n'existe que deux choses à faire absolument :
    a) n'emplyez jamais de noms invalides, de noms qui commencent par un soulignement ou qui incluent un double soulignement
    b) utilisez toujours des NOMS_EN_MAJUSCULE pour les macros et ne songez même pas à écrire une macro qui soit un nomcommun ou une abbréviation[...].
    Le bouquin propose par exemple :
    enums CommeCela;
    variables commeCela;
    variables membres privées commeCela_
    macros COMME_CELA
    sans pour autant défendre l'ultime utilité de cette convention. C'est juste au cas où le lecteur manque d'idée

    bref, j'aime bien l'approche décrite dans ce bouquin, il explique que globalement il est plus utile pour une convention de décider quoi interdire plutôt que quoi imposer.

    exemple
    Soit la notation hongroise est autorisée : s'il en a envie le codeur l'utilise
    Soit elle est complètement interdite : auquel cas celui qui l'utilise sera chatié !

    Imposer une règle de nommae précise et contraignante, c'est être sur qu'elle sera bafouée dès
    le premier bugfix en rush que le client aura demandé pour hier.
    Lorsqu'on est en période de tension, on code comme cela vient et on en oublie souvent les conventions.

  14. #14
    screetch
    Invité(e)
    Par défaut
    c'est vrai que moins il y a de conventions et mieux c'est.

    entre en conflit avec
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    if (test && test2)
    {
    }
    car un petit malin a decidé de corriger la premiere version en
    en ajoutant un espace entre le if et la parenthese.

    et ca, ca parait rien, mais ca casse un peu les burnes de celui qui doit resoudre un conflit pour un changement cosmetique. alors ensuite, plus on a de conventions (nommages, espaces, indentations, parentheses) plus on a ce genre de conflits qui arrivent lorsqu'une bonne ame decide de reindenter car ca lui plaisait pas, ou rajouter des espaces car il en manquait, etc etc

    bref, plus la convention est concise, mieux elle sera respectée et moins elle cassera les pieds des gens. de plus, on verra aussi moins d'affrontement entre les pros et antis.

  15. #15
    Invité
    Invité(e)
    Par défaut
    Une propriété que je trouve intéressante dans des conventions qui me semblent réussies, c'est qu'elles proposent suffisamment de cohérence pour pouvoir permettre des recherches à travers toute la base de code avec un outil de type grep, ou même avec la recherche Windows.

    Si par exemple la convention précise que les opérateurs "->" et "." doivent être collés au nom de la méthode lors d'un appel (et interdit par exemple de passer à la ligne), je peux chercher facilement tous les appels à cette méthode. J'aurais peut-être des faux positifs, mais c'est moins embêtant que de louper des occurrences.

    A titre d'exemple, nous utilisons au boulot un générateur de "pimpls" qui met Visual C++ en difficulté pour les méthodes virtuelles. La recherche par texte devient soudain ma meilleure amie pour les refactorings!

    Carl

  16. #16
    Membre émérite
    Profil pro
    Inscrit en
    Juillet 2009
    Messages
    307
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Juillet 2009
    Messages : 307
    Par défaut
    Citation Envoyé par nikko34 Voir le message
    oui, dans ma boite avec la convention de nommage on se retrouve avec:

    - des codes qui remplacent le nom des classes ( genre GLSF90 )
    résultat: c'est incompréhensible même avec un diagramme

    - une notation pseudo-hongroise horrible avec genre un préfixe cls ou cl pour..... classe!! ( même en Java ou C#!! )

    ....
    Voilà, heureusement là où je suis je n'ai pas à travailler avec ces horreurs et j'utilise la norme que je veux, je ne suis pas le département informatique classique.

    Mais on a beau leur répeter qu'ils vont droit dans le mur, ils continuent. C'est quand même dingue de ne pas vouloir ouvrir un bouquin correct de C++. C'est pas faute de leur avoir indiqué ou rédigé un résumé de 15 pages.
    Ces codes illisibles créent de la valeur pour ceux qui les développent. A coté, celui qui vient d'arriver ne comprend rien, et on peut plus difficilement se passer de celui qui sait ce que GLSF90 signifie.... Le risque c'est de nuire à la compétitivité du projet et de l'entreprise ...

  17. #17
    Membre émérite
    Homme Profil pro
    Recherche du travail
    Inscrit en
    Août 2004
    Messages
    561
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 35
    Localisation : France, Pyrénées Atlantiques (Aquitaine)

    Informations professionnelles :
    Activité : Recherche du travail

    Informations forums :
    Inscription : Août 2004
    Messages : 561
    Par défaut
    Pour mes projets, j'utilise la convention Webkit.
    https://www.webkit.org/coding/coding-style.html

  18. #18
    r0d
    r0d est déconnecté
    Membre expérimenté

    Homme Profil pro
    Développeur informatique
    Inscrit en
    Août 2004
    Messages
    4 290
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Ain (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : Août 2004
    Messages : 4 290
    Billets dans le blog
    2
    Par défaut
    Citation Envoyé par Senaku-seishin Voir le message
    Pour mes projets, j'utilise la convention Webkit.
    https://www.webkit.org/coding/coding-style.html
    Merci pour le lien.
    Cela dit, cette convention ne me plait pas du tout. Bon, elle est visiblement conçue pour un contexte spécial: xcode. Ce n'est pas du "pur" c++, et le monde d'apple est un peu spécial. Mais ça n'explique pas tout.

    Quelques points sur lesquels je ne suis pas d'accord:
    Use spaces, not tabs.
    Je trouve que cette histoire d'espace est d'une autre age. Si l'indentation d'un fichier source ne nous plait pas, la plupart des IDE permettent de réindenter en un raccourci clavier (ctrl+K ctrl A sur msvc par exemple).

    Null, false and zero
    Right:
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
     
    if (condition)
       doIt();
     
    if (!ptr)
       return;
     
    if (!count)
       return;
    Wrong:
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
     
    if (condition == true)
       doIt();
     
    if (ptr == NULL)
       return;
     
    if (count == 0)
       return;
    Je préfère ce qu'ils considèrent comme mauvais. Sur ce point, Stroustrup est de mon côté d'ailleurs. Déjà, on utilise plus NULL, mais nullptr. Et puis je pense qu'il est préférable de spécifier explicitement ce que l'on compare (pour un pointeur: nullptr, pour un booleen: true ou false, etc.). C'est une question de sémantique: donnons du sens à notre code!

    Data members in C++ classes should be private. Static data members should be prefixed by "s_". Other data members should be prefixed by "m_".
    Je pensais que cette règle était définitivement rangée dans les archives des conventions de nommage. Je trouve ça totalement inutile, du coup ça alourdi le code inutilement.

    Je ne vais pas faire la liste exhaustive, mais bon, vous l'aurez compris, je trouve cette convention vraiment pas terrible. Après, elle est peut-être adaptée à xcode, que je n'ai jamais utilisé, donc je ne peux pas dire. Mais pour du c++ classique, non, je n'aime vraiment pas.

Discussions similaires

  1. Convention de nommage
    Par ites dans le forum Langage SQL
    Réponses: 11
    Dernier message: 12/09/2008, 17h00
  2. [PL/SQL] Convention de nommage
    Par dcollart dans le forum Oracle
    Réponses: 1
    Dernier message: 10/07/2006, 16h50
  3. Convention de nommage J2EE ? Ou ?
    Par n!co dans le forum Java EE
    Réponses: 11
    Dernier message: 19/01/2006, 09h22
  4. Petite question sur les conventions de nommage en Java
    Par implosion dans le forum Langage
    Réponses: 7
    Dernier message: 18/01/2006, 15h54
  5. Convention de nommage dans le code
    Par firejocker dans le forum Langage
    Réponses: 4
    Dernier message: 01/08/2005, 14h18

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo