Partage
  • Partager sur Facebook
  • Partager sur Twitter

Faire un namespace d'une seule lettre

    19 octobre 2023 à 20:46:10

    Hello, j'ai envie de faire un projet en C++ et j'ai vu que c'était bien de mettre toutes les déclarations dans un namespace pour que les autres puissent utiliser les fonctions dans leur projet sans avoir de conflit. Le problème c'est que le projet où je vais mettre ces fonctions je vais l'appeler Werdum mais j'ai pas envie de faire un namespace Werdum parce que je trouve que c'est trop long, du coup j'aimerais bien faire juste un namespace "w" vous pensez que c'est une bonne idée ? Comme ça c'est plus rapide à taper

    Merci

    • Partager sur Facebook
    • Partager sur Twitter
      20 octobre 2023 à 0:24:19

      >vous pensez que c'est une bonne idée ?

      Absolument pas.

      >Comme ça c'est plus rapide à taper

      Vous utilisez quoi comme IDE antédiluvien pour qu'il ne fasse pas de la complétion automatique ?

      Si tout le monde avait votre funèbre idée, les namespaces ne règleraient les problèmes de collision de noms.

      Pensez plutôt aux alias de namspace si vous utilisez un vieux clou comme IDE.

      Cela permet de réduire votre flemme à un périmètre restreint.

      • Partager sur Facebook
      • Partager sur Twitter
      Je recherche un CDI/CDD/mission freelance comme Architecte Logiciel/ Expert Technique sur technologies Microsoft.
        20 octobre 2023 à 5:43:30

        Bon, pour ete tres pragmatique :

        - personne d'autres que toi utilisera ton projet, tres probablement

        - un rechercher-remplacer ou la fonction de refactorisation de ton IDE et tu change un namespace en 2 secondes

        Bref, fais comme tu veux

        • Partager sur Facebook
        • Partager sur Twitter
          20 octobre 2023 à 9:40:26

          bacelar a écrit:

          Vous utilisez quoi comme IDE antédiluvien... 

          Qu'est-ce qui te fais dire qu'il utilise un IDE ?

          gbdivers a écrit:

          - personne d'autres que toi utilisera ton projet, très probablement

          Qu'est-ce qui te fais dire que personne d'autre utilisera son projet ?



          • Partager sur Facebook
          • Partager sur Twitter
            20 octobre 2023 à 9:57:12

            >Qu'est-ce qui te fais dire qu'il utilise un IDE ?

            C'est peut-être le vrai problème initiale, ne pas utiliser les bons outils.

            • Partager sur Facebook
            • Partager sur Twitter
            Je recherche un CDI/CDD/mission freelance comme Architecte Logiciel/ Expert Technique sur technologies Microsoft.
              20 octobre 2023 à 10:23:38

              Quel rapport entre les outils et les namespaces ?

              bacelar a écrit:

              Cela permet de réduire votre flemme à un périmètre restreint.

              Qu'est-ce qui vous fait dire qu'il est fainéant ? Parce que moi si j'était fainéant, je ne mettrait pas de namespace.

              -
              Edité par Yann Amard 20 octobre 2023 à 10:30:25

              • Partager sur Facebook
              • Partager sur Twitter
                20 octobre 2023 à 12:27:55

                Salut,

                Yann Amard a écrit:

                Qu'est-ce qui te fais dire qu'il utilise un IDE ?

                S'il n'en utilise pas, ou, justement, s'il en utilise un qui n'est pas capable de fournir un minimum de complétion après avoir écrit trois (ou quatre) lettre d'un espace de noms, il est de toutes façons largement temps qu'il envisage de choisir "les bons outils" pour ce qu'il veut faire.

                Peut être as-tu déjà entendu la phrase

                Un bon ouvrier a toujours de bons outils

                C'est parce que, le plus souvent, les mauvais ouvriers reporteront le blâme sur leurs outils, qu'ils jugent de mauvaise qualité ou inadaptés au travail, alors que les bons ouvriers mettront un point d'honneur à garder leurs outils dans le meilleur état possible et à choisir en toute circonstance l'outil qui sera effectivement le mieux adapté à la tâche qu'il doit effectuer ;)

                Il en va rigoureusement de même pour la programmation, car ce domaine a une très forte composante "créative" se rapprochant carrément de ce que l'on pourrait appeler "de l'art" ;)

                Yann Amard a écrit:

                Quel rapport entre les outils et les namespaces ?

                Le rapport est que la toute première caractéristique d'un "bon" code -- avant même de compiler sans erreur et (si possible) sans avertissement, avant même de faire ce que l'on attend de sa part -- est d'être facilement lisible par "n'importe qui". Ce "n'importe qui" pouvant être ... toi (l'auteur du code) qui revient sur le code alors que tu as eu "tout le temps" d'oublier la logique que tu as suivie pour l'écrire.

                Cette caractéristique de lisibilité facile aura pour principal résultat de rendre la compréhension du code plus facile. Or, si ton code n'est pas "facilement compréhensible", tu vas régulièrement passer des heures à t'arracher les cheveux et à te demander ce qu'il est sensé faire lorsque, pour une raison ou une autre (sans doute pour corriger une erreur à l'exécution), il faudra envisager de modifier ton code.

                Car c'est cette compréhensibilité aisée du code qui te permettra de ... "valider" le fait que le code fait effectivement ce que tu attends de sa part, de te rendre compte qu'il y a -- peut être -- un "cas hors limites" qui est susceptible de survenir et qui n'aurait pas été pris en compte.

                Si bien que, au final, une "lisibilité aisé" te placera dans une situation dans laquelle il sera ... beaucoup plus facile de garantir "la qualité" de ton code en le rendant plusfacile à comprendre, plus facile à corriger et plus facile à faire évoluer)

                Or, les règles suivies par le compilateur font qu'un code proche de

                #include 
                using _ = double;
                _ __(_ ___, _ ____){
                    return ___ /100 *____);
                }
                
                int main(){
                    _ _____=150.0;
                    _ ______=20.0;
                std::cout<<"montant hors TVA : "<<_____<<"\n"
                         <<"montant TVA ("<<______ 
                         << " %)":<<__(_____,______)<<"\n"
                         << TOTAL :"<< (_____ +__(_____,______)<<"\n";
                }

                est parfaitement légal et sera accepté sans le moindre problème par le compilateur qui n'émettra même pas un avertissement :p

                Mieux encore, il fera exactement ce que j'attends de sa part!

                Seulement, si tu n'avais sous les yeux que le code de la fonction __, avec l'alias de type et l'appel à la fonction se trouvant "ailleurs" dans le code, tu aurais ... particulièrement difficile à te rendre compte que cette fonction a pour objectif ... de calculer un montant de TVA sur la base d'un montant hors TVA et d'un taux de TVA.

                On se rend donc assez facilement compte que la lisibilité du code est un aspect primordial ;)

                 Or, pour atteindre cet objectif de "facilité de lecture", il n'y a pas trente-six solutions : il faut impérativement que tous les identifiants -- c'est vrai pour les espaces de noms, les types de données, les noms de données,  de fonctions et de leurs argument -- soient capables de donner une idée "aussi précise que possible" de l'usage auquel ils sont destinés et, dans la mesure du possible, sans que la personne qui lira le code (ce sera peut-être toi ... ou pas ) ne doive commencer à se poser la question de "mais à quoi correspond cette abréviation cmtmhtt"(calcule_montant_tva_montant_hors_tva_et_taux_tva)

                Car, si l'alias de type est supprimé et que l'on utilise des identifiants "cohérents", la fonction pourrait "facilement" être modifiée pour prendre la forme de

                double montantTVA(double prixHT, double tauxTVA){
                    return prixHT/100*tauxTVA;
                }

                ce qui enlève toute ambiguité sur l'objectif même de cette fonction ;)

                Maintenant que l'on a -- je l'espère -- compris l'absolue nécessité de choisir des identifiants qui permettront au lecteur du code de se faire une idée précise de ce que le code est sensé faire, on peut discuter du rapport avec les outils utilisés ;)

                Car le "bon nommage" des différents identifiants va très rapidement nous inciter à choisir des identifiants composés ... d'un nombre de lettres qui risque "d'exploser". Et s'il faut à chaque fois écrire toutes les lettres de ces identifiants, ben, le risque d'une erreur (bêtement, une majuscule au lieu d'une minuscule, ou l'oubli d'une lettre) va -- forcément -- augmenter de manière proportionnelle (voire exponentielle) avec la taille des identifiants.

                C'est à ce niveau là que le choix des "bons outils" va s'avérer essentiel.  Car "les bons outils" sont parfaitement en mesure de retrouver les différents identifiants dés que tu en auras introduit les premières lettres, voire, de te faire plusieurs propositions si, dans un contexte donné, tu te retrouve avec plusieurs identifiants "relativement proches" (commme la fonction value() et la donnée membre value_)

                Donc, si tu choisi les "bons outils" (ceux qui sont effectivement capables de te rendre ce genre de service), et que tu les configure (au besoin) correctement, ils te permettront de limiter énormément le nombre de lettres que tu devras introduire pour accéder à un identifiant dont le nom peut être particulièrement long, mais, en plus, de limiter le risque d'erreur lors de l'accès à ces identifiants.

                Et tout cela (une "bonne politique de nommage" ET les "bons outils") contribuera grandement à te faciliter la vie lors du développement de ton projet ;)

                • Partager sur Facebook
                • Partager sur Twitter
                Ce qui se conçoit bien s'énonce clairement. Et les mots pour le dire viennent aisément.Mon nouveau livre : Coder efficacement - Bonnes pratiques et erreurs  à éviter (en C++)Avant de faire ce que tu ne pourras défaire, penses à tout ce que tu ne pourras plus faire une fois que tu l'auras fait
                  20 octobre 2023 à 13:51:30

                  J'utilise visual studio je sais pas si c'est un IDE mais oui j'ai remarqué qu'il propose automatiquement de finir les mots mais après même en terme de lecture je trouve que c'est plus lisible d'avoir des noms de namespace pas trop longs. Et oui je pense que personne n'utilisera mon projet mais je me demandais aussi si ça poserait un problème si j'utilise une librairie qui propose le même namespace, du coup il y aurait un conflit avec mon code à moi ? Parce que sinon je pourrais aussi faire un namespae Werdum et quand je veux l'utiliser je fais namespace w = Werdum juste pour moi mais ça m'oblige à taper cette ligne c'est un peu pénible. Sinon peut être qu'il vaut mieux faire un namespace de 2 lettres ? Par exemple "we", ça se fait de faire des namespace de 2 lettres ?

                  koala01 merci pour la longue réponse oui je reconnais que c'est bien de choisir des bons noms lisible

                  • Partager sur Facebook
                  • Partager sur Twitter
                    20 octobre 2023 à 15:50:01

                    Yann Amard a écrit:

                    bacelar a écrit:

                    Vous utilisez quoi comme IDE antédiluvien... 

                    Qu'est-ce qui te fais dire qu'il utilise un IDE ?

                    gbdivers a écrit:

                    - personne d'autres que toi utilisera ton projet, très probablement

                    Qu'est-ce qui te fais dire que personne d'autre utilisera son projet ?

                    Merci pour ta contribution a cette discussion.

                    FreyerHoly a écrit:

                    si ça poserait un problème si j'utilise une librairie qui propose le même namespace, du coup il y aurait un conflit avec mon code à moi ? 

                    Ca prend vraiment 2 secondes pour modifier un namespace, meme sur des milliers de fichiers. Fais comme tu le sens et change plus tard si tu y vois des inconvénients a l'usage.
                    • Partager sur Facebook
                    • Partager sur Twitter
                      20 octobre 2023 à 21:33:32

                      Ce qu'il faut bien te dire, c'est que tout ce que l'on peut faire, c'est te donner des conseils et ce, même s'ils sous parfois (souvent) donnés sous une forme "plutôt directive".

                      Car, au final, nous, on n'en a absolument "rien à battre" que tu passes des heures à essayer de te rappeler ce que tu voulais (espérait) faire lorsque tu as écrit un code que tu ne comprends pas (plus) ;)

                      Le truc, c'est que l'expérience aidant -- ce qui implique parfaois de très nombreuses heures à s'arracher les cheveux ;) -- on en est arrivés on en est arrivés à un point où l'on a élevé ces conseils au rang de "règle personnelle" et que l'on espère toujours (plus ou moins secrètement) arriver à convaincre les débutant du bien fondé de ces conseils, quitte à les présenter effectivement sous une forme qui tiendrait plus d'une  "règle devant impérativement être suivie" que sous la forme d'un conseil ;)

                      Ceci étant dit, "une bonne pratique" pour le choix des noms des différents éléments est de partir du principe que plus la "portée" -- comprends: l'espace qui sépare la "définition" de ce nom (quel qu'il soit) de son utilisation -- est importante, plus le nom doit être choisi de manière précise afin d'éviter au maximum au lecteur de se poser des questions comme "mais c'est quoi ce truc?" ou "mais à quoi sert ce machin?" (en anglais, on utilise l'expression "WTF" pour "What The Fuck")

                      Ainsi, un nom simple comme dans le code qui suit ne posera pas trop de problème, car sa définition et son utilisation sont "toute proche":

                      int foo(){ // non, pas ce noms ci 
                      
                          int cpt=0; // on se doute que cela signifie "compteur" 
                          for (auto it : tableau_de_trucs){
                              if(une_condtion_quelconque)
                                  ++cp;
                          }
                          return cpt;
                      }
                      

                      Par contre, surtout pour ce qui est des espaces de noms, il faut te dire que sa "portée" sera ** forcément ** beaucoups plus importante, et que, en plus, ton projet -- comme tout projet "non jetable" -- va "certainement" mettre des parties relativement "indépendantes les unes des autres" en jeu.

                      Tu risques donc, à termes d'avoir un espace de noms "global" qui correspond à "l'ensemble des fonctionnalités que tu as dévelopées dans le cadre de ton projet" et qui contient "plusieurs" autres espaces de noms plus "spécifiques" aux fonctionnalités en questions

                      Et tu risques même de te retrouver dans une situation dans laquelle ces "sous espaces de noms" vont eux même contenir différents espaces de noms "secondaires" qui seront encore plus spécifiques aux fonctionnalités que tu développes.

                      Par exemple, si ton espace de noms "général" est Werdum, il se peut tout à fait que tu aies, dans cet espace de noms, les espaces de noms "généraux" comme

                      • config (tout ce qui permet de gérer la configuration au runtime)
                      • model (les types de données qui seront effectivement manipulés et que l'on appelle également "données métier")
                      • view (tout ce qui permet d'obtenir "une représentation fidèle" des données que l'on manipule, quelle que soit le type de représentation envisagé)
                      • controler (tout ce qui permet d'intervenir sur les "données métier" sur base d'événement survenus au niveau de la vue
                      • logging (tout ce qui permet de "garder une trace" de ce qui a pu se produire lors de l'exécution)
                      • j'en passe, et sans doute de meilleures ;)

                      Et, bien souvent, ces espaces de noms généraux seront eux-même "subdivisés" en espace de noms "plus spécifiques" comme

                      • math (si tu implémentes par toi même certaines fonctionnalités mathémtatiques (comme l'algèbre vectorielle et ou l'algèbre matricielle)
                      • sound (si tu veux émettre du son)
                      • graphics (si tu veux avoir un joli rendu graphique)
                      • physics (si tu en as besoin)
                      • IA (si tu veux que ton programme puisse réagir "par lui-même)
                      • web si ton application doit envoyer / recevoir des données "sur le réseau"
                      • j'en passe, et sans doute de meilleures

                      ce qui te permettra de faire en sorte que chacune de ces parties soit "aussi susceptible que possible" de travailler de manière "autonome et indépendante".

                      Et il se peut même que certains de ces espaces de noms soient eu-même subdivisés en d'autres espaces de noms, et ainsi de suite, en fonction de la complexité de ton projet.

                      Il se peut donc que tu te retrouves avec un accès à

                      Wedrum::Model::Math::Vectors::une_fonctionnalite_quelconque

                      qui est certes particulièrement long, mais qui a au moins l'avantage d'indiquer clairement que la fonctionnalité recherchée fait partie du projet Wedrum et dont le but est de manipuler les vecteurs mathématiques au niveau de la partie s'occupant de "la gestion des données métiers".

                      Tu fais bien sur comme tu le veux, mais si tu te retrouves à un moment à avoir un accès comme

                      W::M::M::V::une_fonctionnalité_quelconque
                      |  |  |  |-> une fonctionnalités dédiées au Vecteurs
                      |  |  |----> à l'aspect mathétatique des vecteurs
                      |  |-------> qui prend en charge les données métiers (les
                      |            vecteur mathématiques)
                      |----------> du projet général

                      ben, tu te rend compte "assez facilement" que cela va rapidement devenir ingérable, n'est-ce pas?

                      De plus, il faut se rappeler que nous disposont de tout plein de possibilités pour "faciliter" l'utilisation des espaces de noms et que, sous réserve de les choisir intelligemment (par exemple, de préférer les alias d'espace de noms à la directive using namespace, à moins que ce ne soit dans une portée particulièrmement limitée), ben, ces possibilités méritent d'être envisagées, et tu arriveras sans doute à concilier "ta fainéantise naturelle" (et tout à fait louable) et le "besoin d 'expressibilité" inhérant à tout projet ;)

                      • Partager sur Facebook
                      • Partager sur Twitter
                      Ce qui se conçoit bien s'énonce clairement. Et les mots pour le dire viennent aisément.Mon nouveau livre : Coder efficacement - Bonnes pratiques et erreurs  à éviter (en C++)Avant de faire ce que tu ne pourras défaire, penses à tout ce que tu ne pourras plus faire une fois que tu l'auras fait

                      Faire un namespace d'une seule lettre

                      × Après avoir cliqué sur "Répondre" vous serez invité à vous connecter pour que votre message soit publié.
                      × Attention, ce sujet est très ancien. Le déterrer n'est pas forcément approprié. Nous te conseillons de créer un nouveau sujet pour poser ta question.
                      • Editeur
                      • Markdown