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++

  1. #41
    Membre éprouvé
    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
    Points : 1 176
    Points
    1 176
    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.

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

    Informations forums :
    Inscription : Mars 2004
    Messages : 99
    Points : 87
    Points
    87
    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.

  3. #43
    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.

  4. #44
    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

  5. #45
    Membre averti
    Profil pro
    Inscrit en
    Juillet 2004
    Messages
    410
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Juillet 2004
    Messages : 410
    Points : 361
    Points
    361
    Par défaut
    - MaClasse
    - MaMethode() et MaFonction()
    - m_monMembre (ex m_strName)
    - p_monPointeur (ex wxButton* p_btnCancel)

    Les noms de fichiers *.cpp et *.h sont en minuscule avec séparation par _ pour la composition des mots.

  6. #46
    Nouveau membre du Club
    Inscrit en
    Septembre 2009
    Messages
    10
    Détails du profil
    Informations forums :
    Inscription : Septembre 2009
    Messages : 10
    Points : 26
    Points
    26
    Par défaut
    1 - question de goût
    2 - nom_de_fonction()
    3 - _variable_membre
    4 - void une_fonction(int mon_int, std::string &ref_chaise)

    Je deteste coller les mots en insérant des majuscules (ClasseOuFonctionExemple), presque tout le monde fait ça mais ça me donne l'impression d'être dislexique

    Autre chose, je colle toujours l'étoile pointeur coté type, c'est plus logique (c'est en faisant ça que j'ai arreté d'avoir peur des pointeurs):
    int* foo;

  7. #47
    Expert éminent sénior
    Avatar de Luc Hermitte
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Août 2003
    Messages
    5 275
    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 275
    Points : 10 985
    Points
    10 985
    Par défaut
    Citation Envoyé par SuperLutin Voir le message
    3 - _variable_membre
    4 - void une_fonction(int mon_int, std::string &ref_chaise)

    Autre chose, je colle toujours l'étoile pointeur coté type, c'est plus logique (c'est en faisant ça que j'ai arreté d'avoir peur des pointeurs):
    int* foo;
    3- Tiens, on n'en avait pas parlé. Petit rappel donc: http://cpp.developpez.com/faq/cpp/?p...s-par-la-norme
    4- pourquoi dire que c'est une référence ? Cela ne change pas grand chose

    Pour le pointeur, c'est une menterie de coller à côté du type car "T* p1, p2" déclare p1 de type T* et p2 de type T. Ceci dit, je fais pareil.
    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...

  8. #48
    Membre expert
    Profil pro
    Inscrit en
    Mars 2007
    Messages
    1 415
    Détails du profil
    Informations personnelles :
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : Mars 2007
    Messages : 1 415
    Points : 3 156
    Points
    3 156
    Par défaut
    Salut

    Dans la boite ou j'étais avant, personne n'utilisait de namespaces et le chemin complet du type était dans la classe. Ca donnait des trucs du genre DPTProjetMachinModuleTrucMaClasse. Les noms de fichiers allaient avec. Et on parle d'une base de code qui fait des centaines de millions de lignes. Rassurez-vous, il y en toujours qui font des choses plus crades que vous. Déjà, si vous utilisez une convention, quelle qu'elle soit, c'est déjà un bon point !

    Pour ma part, quand je démarre le projet, en général :
    1 - MaClasse
    2 - nomDeFonction()
    3 - mon_membre_
    4 - Je ne le fais pas.

    Sinon je m'adapte aux conventions déjà en place.
    Find me on github

  9. #49
    Membre confirmé
    Profil pro
    Consultant en technologies
    Inscrit en
    Octobre 2013
    Messages
    158
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : Consultant en technologies

    Informations forums :
    Inscription : Octobre 2013
    Messages : 158
    Points : 555
    Points
    555
    Par défaut
    Un exemple qui vaut ce qu'il vaut : Les coding standards de l'expérience ATLAS au CERN
    http://atlas-computing.web.cern.ch/a...uidelines.html

    Cet exemple à deux avantages

    * La première version de ce document date de 2002, et a été mis à jours régulièrement (et inclus même Cpp11), c'est donc bien que le projet a été pensé pour durer (au moins jusque 2025)
    * Le code doit rester lisible et maintenable, il faut qu'un étudiant qui a eu en tout et pour tout 20h d'introduction à l'informatique puisse commence à contribuer à cette base de code(quitte à ce qu'un senior ou un spécialiste en info repasse derrière avant le commit)


    Mais après une bonne partie des conventions c'est une question de gout

  10. #50
    Expert éminent sénior

    Femme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Juin 2007
    Messages
    5 186
    Détails du profil
    Informations personnelles :
    Sexe : Femme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : Juin 2007
    Messages : 5 186
    Points : 17 126
    Points
    17 126
    Par défaut
    Citation Envoyé par SuperLutin Voir le message
    Autre chose, je colle toujours l'étoile pointeur coté type, c'est plus logique (c'est en faisant ça que j'ai arreté d'avoir peur des pointeurs):
    int* foo;
    Sauf que c'est source d'erreur.

    Supposons le fragment de code suivant:
    a est un pointeur vers int, mais b est un int.

    Dans une déclaration, une bonne manière de lire est: *a et b seront deux int.
    Ce que je préfère écrire int *a, b;, car on voit mieux que seul a est un pointeur.

    Par ailleurs, je préfère vivement ne déclarer les pointeurs que seuls, auquel cas, il n'y a pas de différence.
    Mes principes de bases du codeur qui veut pouvoir dormir:
    • Une variable de moins est une source d'erreur en moins.
    • Un pointeur de moins est une montagne d'erreurs en moins.
    • Un copier-coller, ça doit se justifier... Deux, c'est un de trop.
    • jamais signifie "sauf si j'ai passé trois jours à prouver que je peux".
    • La plus sotte des questions est celle qu'on ne pose pas.
    Pour faire des graphes, essayez yEd.
    le ter nel est le titre porté par un de mes personnages de jeu de rôle

  11. #51
    Nouveau membre du Club
    Inscrit en
    Septembre 2009
    Messages
    10
    Détails du profil
    Informations forums :
    Inscription : Septembre 2009
    Messages : 10
    Points : 26
    Points
    26
    Par défaut
    Citation Envoyé par Luc Hermitte Voir le message
    3- Tiens, on n'en avait pas parlé. Petit rappel donc: http://cpp.developpez.com/faq/cpp/?p...s-par-la-norme
    Mince, je vais devoir changer. C'est assez étonnant vu le nombre d'équipes qui utilisent cette convention. Merci bien en tout cas.

    Citation Envoyé par Luc Hermitte Voir le message
    4- pourquoi dire que c'est une référence ? Cela ne change pas grand chose
    Pour savoir ce à quoi on n'est en train de toucher. Je te l'accorde c'est pas souvent utile, en fait je l'utilise parce que ça m'a été imposé et que j'ai pris l'habitude.

    Citation Envoyé par Luc Hermitte Voir le message
    Pour le pointeur, c'est une menterie de coller à côté du type car "T* p1, p2" déclare p1 de type T* et p2 de type T. Ceci dit, je fais pareil.
    Je ne déclare jamais deux types différents sur la même ligne.

  12. #52
    Expert éminent sénior

    Femme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Juin 2007
    Messages
    5 186
    Détails du profil
    Informations personnelles :
    Sexe : Femme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : Juin 2007
    Messages : 5 186
    Points : 17 126
    Points
    17 126
    Par défaut
    Concernant les questions initiales, auxquelles je n'ai pas répondu:

    1&2) Dans toutes les langues, on utilises les majuscules qu'en début de phrase, du coup, je préfère ne pas en mettre aux méthodes ou fonctions.
    De même, on a de la place entre les mots, je préfère du coup avoir un _ dans le nom de méthodes.

    Je trouve que server.OpenSession() n'est pas confortable à lire, je préfère server.open_session(...).

    Cela dit, mon style actuel sera plutot connection.open(...), ou server.connectTo(...);.

    J'essaie d'avoir des noms de méthodes très courts: un verbe ou un nom, selon que se soit une action ou une inspection:
    • connectTo, open, close, raise, increment, load, parse...
    • status, x, y, size...
    • des opérateurs: parenthèses ou crochets pour l'indexation, parenthèses de foncteur, << pour des conteneurs (habitude prise avant C++11 et les initialiseurs)
    • des opérateurs mathématiques pour les objets mathématiques.


    Pour les fonctions libres, je suis un peu plus verbeux, mais j'utilise au maximum les namespaces pour réduire les noms.

    ainsi, le produit scalaire de deux vecteurs sera probablement:
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    namespace math{
    namespace geometrie{
     
    template <typename T>
    double scalar(vector<T> const&, vector<T> const&) {...}
     
    }//geometrie::
    }//maths::
     
    namespace geo = math::geometrie;
    int main() {
        geo::vector<double> a(1,2,3), b(3,4,5);
        return int( geo::scalar(a,b) );
    }

    3) Comment nommer les membres et les classes?
    Ca dépend.

    Pour une classe courte comme un point, j'utiliserai ce genre de style:
    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
    template <typename PRECISION>
    class point {
    public:
        typedef PRECISION precision_type
    private:
        precision_type x_, y_;
    public:
        static point polar(precision_type r, precision_type theta) {...}
        static point cartesian(precision_type x, precision_type y) {...}
    private://ou protected
        point(precision_type x, precision_type y) : x_(x), y_(y) {}
     
    public:
        point(point const& p) : x_(p.x_), y_(p.y_) {}
     
        precision_type x() const {return x_;}
        precision_type y() const {return y_;}
     
        precision_type r() const {/*...*/}
        precision_type theta() const {/*...*/}
    };
    Pour des classes plus grandes, les membres sont rarement exposés explicitement, et je n'ai pas de fonction au nom du membre.
    Dans ce cas là, je n'ai pas de _.

    Par contre, j'aurai probablement un typedef pour chaque conteneur inclus.


    4) Il y a trois sortes de noms de variables dans une fonction: les paramètres, les locales et les membres (pour une fonction membre).
    Je considère qu'une fonction est soit courte soit implémentée dans un .cpp.
    Dans le premier cas, si je n'arrive pas à créer un nom pour une locale a causes des paramètres, la fonction est trop longue, et mérite probablement un découpage.

    Par ailleurs, j'essaie de ne pas avoir de locales quand je peux. La très grande majorité des fonctions que j'écris font moins de 10 lignes, et n'ont pas plus de deux variables ayant la fonction pour scope.
    J'ai facilement un itérateur par-ci, une temporaire par-là, mais toujours je limite toujours sa portée à un sous-bloc.
    Je me refuse à écrire une fonction ayant besoin de plus de trois ou quatres variables.

    Par exemple, voici une fonction de mise en cache d'un fichier (au format précis, nommé pour l'exemple TauMap) :
    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
    void cache::loadTauMap(option_manager const& options) {
       if (!shallLoad()) return;
     
       long read=0;
       long saved=0;
     
       logger.info()<<"chargement en cours"<<std::endl;
     
       TauMapLoader fichier( options.get(option_taumap) );
       while (fichier.next()) {
          ++read;
          if (fichier.bad_line()) {
             logger.error()<<" ligne invalide :"<< fichier.report()<<std::endl;
             continue;
          }
     
          data.insert(
             std::make_pair(
                TauMap_key( fichier.champ1() ),
                TauMap_value( fichier.champ3(), fichier.champ4() )
             )
          );
     
          logOnLoad(++saved);//fera du log selon certains critères
       }
       fichier.close();
       logger.info()<<"fin de chargement"<<std::endl;
       logger.info()<<"lues:"<<read<<" gardées: "<<saved<< std::endl;
    }
    30 lignes de codes, 3 temporaires, chacune répondant à un besoin publique de la fonction.
    Et encore, j'ai souvent un line_counter<long>, classe contenant les compteurs, et proposant trois fonctions accepted() , rejected() et useless(). (cette dernière pour les lignes valides mais filtrées)


    En règle général, j'évite d'avoir plus de quatre indentations réelles (je n'indente pas le namespace, et j'ignore l'indentation de base dans une classe, ainsi que le try catch).
    Ca me laisse deux boucles, un if, et une construction complexe.

    Cela suppose de me reposer sur des capsules raii dédiées aux détails de code (compteurs loggant, par exemple, mais aussi type avec validation, optional, etc).
    Et surtout, préférer tester les erreurs que la validité.
    Un if qui se termine par un return ou un continue/break permet de désindenter d'un cran le reste de la boucle/fonction.
    Mes principes de bases du codeur qui veut pouvoir dormir:
    • Une variable de moins est une source d'erreur en moins.
    • Un pointeur de moins est une montagne d'erreurs en moins.
    • Un copier-coller, ça doit se justifier... Deux, c'est un de trop.
    • jamais signifie "sauf si j'ai passé trois jours à prouver que je peux".
    • La plus sotte des questions est celle qu'on ne pose pas.
    Pour faire des graphes, essayez yEd.
    le ter nel est le titre porté par un de mes personnages de jeu de rôle

  13. #53
    Expert éminent sénior
    Avatar de Luc Hermitte
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Août 2003
    Messages
    5 275
    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 275
    Points : 10 985
    Points
    10 985
    Par défaut
    [Réponse au message de SuperLutin]

    3- Tant que l'on ne double pas les tirets-bas ou que l'on ne joue pas avec des majuscules, c'est bon. Mais par précaution, je préfère interdire. La règle complète est assez complexe : elle dépend en plus du contexte.
    Après, c'est répandu grâce à d'autres langages où cette convention est assez répandue.

    4- Ben ... n'est pas la faute aux fonctions qui sont trop longues pour qu'à la fin on puisse avoir des doutes quant à ce que l'on modifie ? De mon côté, j'utilise un post-fixage des paramètres (par un tiret-bas). Ce qui a un peu le même effet : de repérer les modifications des choses qui viennent de l'extérieur. Si à l'intérieur de ma fonction je crée un alias sur un itérateur déréférencé, la portée du déréférencement est assez petite normalement, et je n'ai pas besoin de savoir que c'est une référence.
    Si je devais employer une telle politique de nommage (ref_...), je serai embêté lors des refactorings en vue d'optimisation que j'applique régulièrement sur les codes qui m'entourent (-> remplacer des copies d'itérateurs déréférencés par des références donc, de préférence constantes)

    x- pour les déclarations, je fais comme toi : une par ligne, mais je ne perd pas de vue que ce n'est pas forcément plus logique vu la syntaxe du langage.
    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...

  14. #54
    Expert éminent sénior
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Février 2005
    Messages
    5 059
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 52
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Conseil

    Informations forums :
    Inscription : Février 2005
    Messages : 5 059
    Points : 12 095
    Points
    12 095
    Par défaut
    Le "chacun sa tambouille", ça me défrise grave.

    Pour ceux qui, comme moi, ont une mentalité de Gestapo :
    https://msdn.microsoft.com/en-us/library/hh419384.aspx

    Mais, les conventions de codage ne sont efficaces que si elles sont appliquées de la même manière par tous, et respectées par tous.

    Si vous êtes moins amateur d'imperméables noirs, les règles sont désactivables unitairement. Prévoyez une AG pour accorder les violons de tout le monde.
    Et si vous êtes carrément du coté obscure du management, vous pouvez en ajouter.

    Sinon, je crois qu'avec Roselyne (futur VS2015), il y aura même les petits zigouigoui comme dans le correcteur orthographique de Word pour souligner vos "erreurs" dans le code pendant la frappe.

  15. #55
    Nouveau membre du Club
    Inscrit en
    Septembre 2009
    Messages
    10
    Détails du profil
    Informations forums :
    Inscription : Septembre 2009
    Messages : 10
    Points : 26
    Points
    26
    Par défaut
    Réponse au message de Luc Hermite

    3- Je viens de rajouter la même règle à mes conventions.

    4- Ça aide lors de fonction trop longues. Oui les fonctions trop longues sont dangereuses, mais je n'ai pas toujours la possibilité de refactoriser ce qui a été fait sur un projet avant que je débarque, et en entreprise on ne choisi pas ses conventions de codage. Cela dit je me rend bien compte que c'est une habitude un peu inutile qu'on retrouve sur mes projets perso, mais ce n'est pas bien grave.

  16. #56
    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 : 49
    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
    Points : 16 213
    Points
    16 213
    Par défaut
    Citation Envoyé par bacelar Voir le message
    Sinon, je crois qu'avec Roselyne (futur VS2015)
    Roslyn, c'est uniquement VB/C#.
    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.

  17. #57
    Expert éminent sénior
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Février 2005
    Messages
    5 059
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 52
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Conseil

    Informations forums :
    Inscription : Février 2005
    Messages : 5 059
    Points : 12 095
    Points
    12 095
    Par défaut
    Alors pas de "live code analyser" en C++ sous VS2015 ?
    Mon coté obscure de la force est triste.

  18. #58
    Membre éprouvé
    Profil pro
    Inscrit en
    Juillet 2009
    Messages
    307
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Juillet 2009
    Messages : 307
    Points : 983
    Points
    983
    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 ...

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

    Informations professionnelles :
    Activité : Recherche du travail

    Informations forums :
    Inscription : Août 2004
    Messages : 561
    Points : 1 320
    Points
    1 320
    Par défaut
    Pour mes projets, j'utilise la convention Webkit.
    https://www.webkit.org/coding/coding-style.html
    Avoir un regard neutre sur notre vie dénuée de sens, c'est la voir tel un ignorant
    ------------------------------------------------------------------------------------------------------

  20. #60
    r0d
    r0d est déconnecté
    Expert éminent

    Homme Profil pro
    tech lead c++ linux
    Inscrit en
    Août 2004
    Messages
    4 262
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Ain (Rhône Alpes)

    Informations professionnelles :
    Activité : tech lead c++ linux

    Informations forums :
    Inscription : Août 2004
    Messages : 4 262
    Points : 6 680
    Points
    6 680
    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.
    « L'effort par lequel toute chose tend à persévérer dans son être n'est rien de plus que l'essence actuelle de cette chose. »
    Spinoza — Éthique III, Proposition VII

Discussions similaires

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

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