Est l'aide de souligner suffixe pour les membres bénéfique?

class C {
 private:
  int member_; //here is the underscore I refer to.
}

Ce trait de soulignement est recommandé par Google Guide De Style et Geosoft du C++ Guide de Style.

Je comprends qu'il y a des opinions différentes et des goûts.

Je veux demander à des gens qui ont utilisé ou qui ont été forcés de l'utiliser si ils ont jugé bénéfique, neutre ou nocif pour eux. Et pourquoi?

Voici ma réponse:

Je comprends poser des motivations derrière elle, mais elle ne me convainc pas.
Je l'ai essayé et je n'ai eu un peu de désordre partout dans la classe, mais en plus simple initialisation des membres dans le constructeur. Je n'ai pas rencontré de situation où le trait de soulignement contribué à différer entre la variable membre privée et d'une autre variable (sauf dans les cités de l'initialisation).

Dans cette lumière, je considère que ce style de nuisibles.

  • Subjectif en fait. Je ne suis pas en faveur de cette convention de nommage soit.
  • Pourriez-vous préciser pourquoi vous ne l'aimez pas?
  • Fuite des traits de soulignement sont pas plus faciles à 'spot' si vous voyez ce que je veux dire. Et c'est moche. Ha...
  • Je suis peut-être fou, mais il semble que la mise il underscore à la fin, c'est la violation d'autres guides de style que de l'état les plus importantes variations d'un nom doit être au début. Pour moi, division des variables dans les régions (membre vs non-membre, etc) est à peu près aussi grands que vous pouvez obtenir, mais j'ai une préférence hiérarchique des conventions.
  • Mais alors, vous êtes mieux éviter d'utiliser des caractères de soulignement au début, à cause de la norme ANSI C. C'est pourquoi beaucoup aussi utiliser un m_ préfixe.
InformationsquelleAutor | 2009-10-27
  1. 22

    Eh bien, puisque personne ne le mentionne: l'ajout d'un trait de soulignement à la variable de membre vous permet de nommer votre getter et setter avec "conceptuelles" nom de la variable.

    ex:

    class MyClass
{
   int someMember_;

public:
   int someMember() const { return someMember_; }
   void someMember( int newValue ) { someMember_ = newValue; }
};

    pas que j'utilise ce style si.

    • +1. C'est le style que j'utilise. Je trouve qu'il est très pratique pour donner le getter/setter le même nom.
    • La question est de savoir pourquoi vous avez besoin de getters/setters à tous. Ils vous achètent très peu de non-encapsulé, direct, de l'accès des membres. Si vous avez un faible une abstraction, ce qui est la classe? Pour moi, ils semblent pseudo-OO.
    • Eh bien je suis d'accord que le fait d'avoir à la fois un getter et setter est habituellement une odeur, mais cela peut s'appliquer que pour un getter (qui je pense est plus justifié). Aussi nous ne vivons pas dans un monde idéal, et peut-être vous avez juste besoin de faire la transition à partir d'un membre du public à l'aide de méthodes getter et setter avant le refactoring tout pour être un "idéal de la programmation orientée objet". Si vous voulez une discussion sur les méthodes getter et setter, je pense qu'il y en a beaucoup sur ce site ;o)
    • Bien que j'ai tendance à utiliser m_ et s_ préfixes pour accomplir cela, au lieu de la fuite de soulignement, c'est ma raison la plus fréquente pour le faire. Je suis pour la protection des membres de la classe de tomber accidentellement caché par le temps.
    • Pour mon goût à l'aide d'un préfixe (m_) fait le même travail. Aussi, plutôt que d'ajouter un _ suffixe je pense qu'il est préférable d'utiliser this-> chaque fois que vous accédez à un membre. this-> précise que je suis se référant à un objet contenu par *this. Aussi this est un mot clé qui est mis en évidence et highlightning est flatteur vos yeux (sauf si vous changé de rose sur fond vert) 🙂
    • Il travaille pour les plus complexes des poseurs qui sont l'achat de quelque chose de plus brut d'accès trop. void someMember( int newValue ) { validate(newValue); someMember_ = newValue; }
    • Intéressant de noter que c'est la convention de la Norme C++ de la Bibliothèque utilise. Cf. size(), begin(), etc. dans de nombreux contenants (pas get_size(), get_begin()). De même pour certains des rares organismes de réglementation, par exemple width(streamsize). Évidemment, le Standard ne veut pas dire la façon dont les variables membres devraient être nommés, mais il empêche de nommage est la même que pour leur respective des "getters" (en fonction de la mise en œuvre).
    • Le C++ standard library est une vieille bête et a ramassé les verrues d'origine très différente. La différence notable entre size() et begin() etc. d'un côté, et ces méchants getters et setters [PDF] tout le monde semble aimer l'autre, c'est que les premiers sont des concepts inhérents à l'idée d'un conteneur. (Il n'est pas beaucoup d'utilité à avoir des trucs dans un récipient si vous ne pouvez pas compter un énumérer il.) Aussi, en C++03, std::list a été autorisé à calculer size() à la demande, plutôt que de chercher une valeur stockée.
    • Le principal avantage de l'utilisation des getters/setters, même aussi simple que dans l'exemple, directe, accès membres, c'est que dans le futur si vous avez besoin de changer la logique d'accès aux plus avancés (par exemple, ajouter de verrouillage de paramètre ou de validation), vous n'aurez pas besoin de modifier tout le code d'accès du membre. En fait, c'est probablement le principal avantage donné par n'importe quel type d'encapsulation à être libre de changer de encapsulé mise en œuvre sans risque de rupture les clients. Je me demande pourquoi tout développeur expérimenté d'argumenter avec cette.
    • Je suis d'accord, que parfois à l'aide d'un code est de petite taille et/ou la probabilité que le changement dans l'accès logique est très faible. Dans de tels cas, il peut être raisonnable de ne pas écrire le standard code d'accès pour les getters/setters à l'avance, et ajouter en cas de besoin. Mais ce n'est pas la règle, mais plus comme une exception. L'importance des getters/setters est si élevée qu'il y a des générateurs pour eux dans quelques IDEs (comme JetBrains IDÉE), et même une syntaxe spéciale pour eux dans certains langages (comme C#).
    • Pourquoi ne pas tout simplement lire le PDF j'ai fait un lien dans mon précédent commentaire? Lorsque vous avez des getters/setters pour les valeurs privées, vous avez déjà jeté l'encapsulation par la fenêtre et de la nécessité de repenser la conception de votre. Oui, un setter est un niveau d'abstraction plus que l'accès en valeur directe, mais seulement une légère augmentation de l'abstraction. Il apporte très peu d'avantages, et ne peut pas contrer le massif des problèmes dus à la manipulation de la notion de privé donnée, peu importe par quel syntaxe.
    • merci pour votre réponse, même si les demi-année plus tard. J'apprécie vraiment votre attention. Dans le fichier PDF Conrad définit quasi-classes que ceux qui ont des getters/setters pour presque chaque membre de données. Et puis, il est précisé que la quasi-classes ne servir à rien. Cela ne s'applique pas à notre conversation, mais, depuis, je ne défends pas les classes qui ont presque tous les membres exposés. Je viens de plaider en approche, quand, si vous avez besoin d'exposer membres, vous feriez mieux de le faire par getter/setter au lieu d'exposer le membre lui-même.
    • vous vous demandez quels sont les avantages de getters/setters (comme Conrad fait également dans son article), et je vais reformuler mon argument précédent. Avec getter/setter vous êtes libre de le modifier ultérieurement votre application: vous pouvez ajouter de la validation, de verrouillage, d'optimisation, ou vous pouvez même supprimer le sous-jacent membre. Si vous étiez à exposer ce membre directement, vous devrez modifier tous les endroits où ce membre ont été utilisés à l'extérieur de la classe. Dans certains cas, il peut s'avérer difficile, voire impossible.
    • Et non, quand on ajoute des getter/setter pour une classe, nous n'avons pas nécessairement jeter incapsulation loin. Fonction membre get_x(), set_x() ne pas exposer au client, qu'il est nécessairement un membre x à l'intérieur de la classe qui est en train d'être lues et écrites par ces méthodes. Cela peut tout simplement pas être vrai. Les membres seulement dire qu'il y a une propriété conceptuelle x d'une classe, qui peut être lu et écrit. Comment cette propriété est mis en oeuvre, eh bien, encapsulé.
    • J'ai combattu ce non-sens, trop souvent, je suis fatigué de il. Par ailleurs, mon dernier commentaire contient déjà tout ce qui est nécessaire pour réfuter vos arguments. La MAIN.
    • Je suis désolé que vous voyez cette conversation comme un non-sens de la lutte. Je ne suis pas un locuteur natif anglais et peut-être certains de mes mots sont durs, mais je ne voulais pas dire cela à tous les.
    • Je suis fatigué de ce que vous avez dit, pas la façon dont vous l'avez dit. J'ai été la lutte contre les accesseurs et mutateurs depuis que j'ai appris qu'ils sont mauvais, parfois, dans le milieu des années 90. Tout ce que vous avez dit j'ai déjà réfuté – dans le commentaire vous a répondu. En Plus j'ai lié à mon article préféré sur eux. Maintenant, vous pouvez lire tout ce qui à nouveau et de trouver pourquoi je pense que vos arguments sont un non – sens- ou de vous rendre sur l'écriture de ces abominations. haussement d'épaules

    InformationsquelleAutor n1ckp
  2. 11

    Si vous besoin ce trait de soulignement afin d'informer les membres de la classe à partir d'autres variables, vous avez probablement trop grandes fonctions de membre pour voir instantanément ce qui est une variable ou le paramètre.

    J'aime toujours parce qu'il facilite membre paramètre de la fonction de nommage: 

    class person
{
public:
  person(const std::string& first_name, const std::string& last_name)
    : first_name_(first_name), last_name_(last_name) {}

  //.......

private:
  std::string first_name_;
  std::string last_name_;
};
    • je le fais de cette façon aussi, bon style
    • Vous pouvez bien sûr éviter les hongrois verrues en ajoutant l' _ pour les paramètres au lieu de les membres.
    • Oui, je pourrais. Mais alors je dois toujours ajouter un _ suffixe pour les paramètres (et ce serait que de l'acheter moi, sauf pour le fait d'avoir mon propre convention qui est en arrière de tout le monde) ou je suis de retour pour ad-hoc paramètre de renommer en raison des affrontements avec les membres de la classe (qui à éviter, c'est la raison pour laquelle j'ai ajouter un _ pour les membres de la classe).
    • Pourquoi ne pas utiliser person(const string &the_first_name, const string &the_last_name); l'Ajout d'un arbitraire de la décoration pour les noms de paramètre dans le constructeur que apparaissent dans le constructeur. Alors que first_name et last_name doivent être utilisés plusieurs fois dans le contexte de la classe. Il semble que le trait de soulignement suffixe et des conventions similaires pour les membres de sacrifier la lisibilité des noms de membres afin de rendre les paramètres du constructeur plus lisible. La lisibilité des paramètres du constructeur noms vraiment d'importance?
    • Je suppose que c'est juste une question de préférences personnelles. Pour moi, votre the_... préfixe de façon plus visuelle de l'encombrement de mon ..._ suffixe. Mais j'insiste sur ni objectivement mieux. J'ai travaillé dans de nombreux projets avec les différentes conventions et, peu importe à quel point ils semblent au premier abord, après quelques mois, ils sont tous à un autre.
    • Oui, je suis d'accord "the_" ou que ce soit dans le constructeur de la liste des paramètres est plus fouillis. Cependant, ce désordre apparaît exactement une fois dans une classe (dans le constructeur de la liste des paramètres). Il semble que le fait de mettre "_" sur chaque membre est purement pour le rendre pratique pour construire des objets dans le constructeur de l'initialiseur de la liste. Je sais que c'est pas une grosse affaire, mais peut-être que C++ serait considérée comme une plus belle langue si les gens n'avaient pas l'utilisation d'une telle convention. En attendant, j'utilise tout ce que la convention de l'équipe utilise de toute évidence, c'est plus important que les préférences personnelles.
    • En fait, vous n'avez pas besoin d'arguments du constructeur diffèrent des noms de membres de faire une telle initialisation. Même :first_name(first_name) pourrait fonctionner ici, si vous n'utilisez pas _ suffixe.
    • En effet, ce n'est pas nécessaire par le compilateur. Toutefois, l'homme a besoin d'elle.
    • Comment distinguer la non-statique des membres statiques à l'aide de cette convention (si vous le souhaitez)?

    InformationsquelleAutor sbi
  3. 10

    - Je utiliser "m_" comme préfixe pour un membre normal de variables et de "s_" statique des variables membres.
    Ainsi, le champ d'application est directement visible.

    • eww, hongrois verrues!
    • Oui, la visibilité de la portée est la principale motivation pour l'utilisation de ces préfixes/suffixes. Mais avez-vous un exemple d'une situation où le savoir de la portée des variables à partir de la variable nom de l'aide?
    • c'est simple, vous êtes dans une sorte de grand méthode et vous avez hérité d'un autre type. Vous avez besoin de savoir, ce qu'il fait. Il est beaucoup plus facile, si vous savez la portée de la variable. Une modification locale de la valeur a beaucoup moins d'importance qu'un changement de l'état de classe. C'est pourquoi vous avez besoin de connaître la portée.
    • il y a toujours le cas des états fonctions de définition où le paramètre entrant peut alors être simplement le nom de membre moins le trait de soulignement. Ce genre de style de sida dans la compréhension générale.
    • J'utilise aussi "m_" et "s_" pour le C++. L'un des avantages est que cette fonctionnalité peut distinguer les membres et d'autres identificateurs ensuite. Donc je ne pense pas, une fin "_" est utile.
    • Pour une alternative à la notation hongroise, vous pouvez vérifier ma réponse ici (même si la réponse n'est pas directement lié à ça): stackoverflow.com/questions/469696/... même s'il est probablement ajouter une petite surcharge, mais le compilateur doit être en mesure d'optimiser loin (citation nécessaire pour prétendre tous les deux).
    • Je déteste vraiment les m_ convention. Les variables de membre sont trop normal, d'un événement pour une surprenante convention qui tend à masquer la variable de nom réel.
    • Je me demande comment il arrive qu'une fuite de soulignement est déclamée à pour être laid, distrayant et autres joyeusetés, tandis que les m_, ce qui est beaucoup plus d'une verrue (et n'était même pas demandé à ce sujet), est voté par une foule silencieuse. Voilà pour les arguments rationnels. :)
    • Je peux facilement venir avec au moins trois arguments. 1. Le plus important devrait aller dans le début (plus facile à repérer avec les yeux). 2. Facile à filtrer dans Intellisense par, juste en tapant le préfixe. 3. Facile de distinguer les non-statique et statique des membres (comment distinguer les membres statiques à l'aide de la fuite de soulignement?)

    InformationsquelleAutor swegi
  4. 6

    Pour moi l'avantage de ce style de décoration des variables de membre est qu'il fonctionne bien avec l'auto complète des fonctionnalités des éditeurs de texte. Un préfixe de décoration vous demande de taper plus de caractères avant un solide deviner ce que tu veux dire peut être faite.

    InformationsquelleAutor Andrew Khosravian
  5. 4

    Je pense que c'est important de faire la distinction entre les variables de classe et locales (et mondial si vraiment nécessaire). Comment vous le faites, n'est pas importante - juste être cohérente.

    class Foo
{
  int mMember;
  int member_;
  int _member;
  int m_Member;
};

    Tous les styles vous donner les informations dont vous avez besoin. Aussi longtemps que vous restez avec le même style de tous les temps, pas de problème. Parfois, d'autres personnes ont besoin de travailler avec votre code (par exemple, lorsque vous créez une bibliothèque, ou si vous travaillez avec une communauté). Ensuite, il pourrait être une bonne idée de coller avec le plus utilisé de style dans le C++ de la communauté.

    Désolé, je ne peux pas répondre à ce style.

    • Éviter des traits de soulignement, il ya des situations où vous ne devriez pas les utiliser (suivi par une lettre majuscule par exemple) et c'est comme un mal de tête à se souvenir exactement de ce qu'ils sont... et juste trop confus à la fin.
    • Ce genre de situations? Sans quelques exemples, qui sonne un peu comme une "eh bien, nous n'avons toujours fait de cette façon." Souligner les préfixes sont largement utilisés, mais pas exactement la norme.
    • Les règles exactes concernant des traits de soulignement sont: 1. Tout identificateur de l'utilisation consécutive de deux traits de soulignement ou commençant par un caractère de soulignement suivi par une lettre majuscule sont réservé à la mise en œuvre dans toute la portée (\w*__\w* et _[A-Z]\w*); 2. Un identificateur commence par un trait de soulignement est réservé à la mise en œuvre dans portée globale (_\w*). Je ne me souviens pas exactement paragraphe, mais c'est quelque part sur DONC.
    • Parfait, merci. Pour l'enregistrement, il ressemble à la discussion principale est dans le stackoverflow.com/questions/228783/....
    • J'ai commencé à utiliser un "_" (comme _name)pour les variables de classe, n'a jamais eu un problème, et ils sont plus faciles à repérer que comme un suffixe(name_). J'ai aussi obligatoirement utiliser le "cette." n'importe quoi, donc un setter lirait comme ceci: setName(String name){this._name = nom;} de Cette façon, il est impossible de les confondre.
    • Donc, si vous n'utilisez jamais de pointe supérieure lettres dans les noms de vos membres, alors vous ne risquez jamais de clash avec la mise en œuvre noms en ajoutant un trait de soulignement. Et vous avez seulement besoin de penser qu'une seule fois.

    InformationsquelleAutor Tobias Langner
  6. 3

    Je suis venu avec ce style de façon indépendante au début de mon codage C++ jours (fin des années 80, début des années 90), car j'ai rencontré plusieurs situations confuses dans lequel j'avais toujours revenir à la classe d'en-tête pour déterminer la variable qui a été vraiment une variable membre.

    Une fois que j'ai commencé à voir d'autres personnes de code C++ qui a fait la même chose, j'étais plutôt heureux de constater que j'avais remarqué un problème que d'autres personnes et que la solution que j'ai adopté pour moi était quelque chose que d'autres personnes ont aussi pensé.

    Ce n'est pas souvent utile, mais c'est assez inoffensif et quand il est utile, il est très utile.

    C'est aussi pourquoi je déteste vraiment l'm_ style. Il n'est pas anodin, et je pense que l'ajout de la laideur n'est pas la peine de la prestation.

    J'utilise un S_ préfixe de fichier portée des variables statiques de classe et les variables statiques qui ne sont pas constantes. Ils sont un peu comme des variables globales, et je pense que leur utilisation doit être signalé à voix haute.

    • +1 pour s_ (ou même g_) préfixe. Comme Google guide de style (qui, autrement, défenseurs de la fin trait de soulignement) ils ont aussi ajouter une remarque à envisager de préfixer les variables globales avec g_. Pour les mêmes principes s_ semble relativement naturel, trop.
    InformationsquelleAutor Omnifarious
  7. 3

    C'est essentiellement un argument religieux de sorte que vous n'ayez pas l'intention de parvenir à un consensus sur ce style. FWIW, je utiliser ce style pour mon variables de membre pour les raisons déjà exposées par d'autres, par exemple:

    class Foo
{
public:
  Foo(std::string name, int age) :
    name_(name),
    age_(age)
  {
  }

  std::string name() const { return name_; }
  void name(const std::string& name) { name_ = name; }

  int age() const { return age_; }
  void age(int age) { age_ = age; }
private:
  std::string name_;
  int age_;
};

    Suffit pas d'adopter quelque chose que vous êtes heureux avec et rester avec elle.

    InformationsquelleAutor Rob
  8. 3

    C'est venu dans la discussion où je travaille, mais avec la programmation Java. Mais je pense que cela s'applique à C++. Ma réponse est que les IDE ont une fonction pratique de la coloration variables de membre de classe. Dans Eclipse, ils virent au bleu. Le trait de soulignement est superflu. Comme une autre affiche, "il EW, hongrois verrues!!". 1980 appelle et veut, c'est la notation hongroise de retour.

    • Je agreee. Ces diverses notations étaient certainement utile il y a quelques années, mais aujourd'hui, nous avons le code de surligneurs, même dans les formulaires web. Et pour être honnête, la couleur de l'information est plus naturel pour les êtres humains que des caractères bizarres. Il est également beaucoup plus personnalisable, chaque membre de l'équipe peut utiliser son propre code de couleur, sans affecter la lisibilité du code pour les autres.
    InformationsquelleAutor user866475
  9. 2

    Nous suivre possibility.com's norme de codage C++ , qui dit de préfixer les variables de membre avec un "m", mais j'ai aussi fait un peu de travail en vertu de Google guide de style.

    Comme vous le dites, il n'est pas strictement nécessaire, surtout si vous avez une IDE qui attribue différentes coloration syntaxique pour les variables membres. Cependant, je pense que certains type de schéma cohérent de nommage, pour vous permettre de voir en un coup d'œil si une variable est une variable de membre, est très intéressant:

    • Simplifié paramètre de nommage, comme dans sbi réponse, est l'un des bénéfices.
    • Un cohérente style de codage est importante, quel que soit le style que vous choisissez. Idéalement, tout le monde sur l'équipe serait d'utiliser le même style de codage, de sorte que vous ne pouvez pas dire à un coup d'oeil qui a écrit un article de code. Cela contribue en apportant de nouveaux développeurs dans l'équipe et avec les méthodes agiles tels que l'absence de code de la propriété et est encore plus important avec les projets open source qui peut attirer une variété de contributions.
    • Le plus important, lisibilité peuvent grandement bénéficier de l'avoir tout le code de suivre un assez stricte de style qui met en évidence les types d'identificateurs de ce genre. La différence entre être en mesure de dire en bref qu'une variable est un membre et d'être en mesure de dire à partir de la recherche au niveau local déclarations de variables sont peut-être petits, mais à la suite d'une bonne norme de codage permettra de faire de nombreuses petites différences dans un corps de code, et il peut faire une énorme différence dans la façon dont facile le code est à suivre et comment il est facile de se lancer dans l'inconnu section de code.

    (Vous avez mentionné que vous avez donné à ce style d'essayer, mais si c'est seulement pour une partie de code et uniquement pour le code qui vous étaient déjà familiers avec, alors il est plus difficile de voir la lisibilité des prestations qu'à la suite d'un style de codage comme ceci pour l'ensemble de la base de code peut apporter.)

    Tout cela est dans mon expérience, votre kilométrage peut varier, etc.

    InformationsquelleAutor Josh Kelley
  10. 1

    il ya un plus de "style", qui suggère de déclarer des membres de la classe ci-dessous:

    class Foo{
    int m_value;
public:
     //...
};

    j'ai trouvé qu'il utilisable. mais c'est juste mon point de vue.

    • La différence entre m_value et value_ est une simple touche de clavier... Est-ce vraiment ajouter jusqu'à assez de gain de temps pour mener des batailles sur elle? 🙂
    • les goûts diffèrent;)
    • ce n'est pas le supplément de frappe, c'est que l'm_ préfixe a beaucoup plus d'impact visuel et, à mon humble avis, tend à mettre l'accent sur la variable du nom, qui je pense est le plus important.
    InformationsquelleAutor varnie
  11. 1

    Je suis d'accord avec Tobias qu'il y a un avantage pour certains de la convention-quelle qu'elle soit -- la mise en évidence des variables de classe. D'autre part, j'ai invariablement trouver que de telles conventions de rendre le code "flux" de moins en moins bien. C'est juste plus facile à lire "totalPrice = productPrice + tva", puis "m_totalPrice = l_productPrice + l_salesTax" ou quoi que ce soit.

    En fin de compte, je préfère juste les laisser tous les noms de champ sans décor, et ont assez peu de variables de classe que de garder une trace d'eux n'est pas un problème. Dans les constructeurs et les setters, j'ai mis un préfixe ou un suffixe sur le paramètre, ou en Java en général, je distinguer la variable de classe avec".", comme:

    public Foo(int bar)
{
  this.bar=bar;
}

    (Pouvez-vous le faire en C++? Ça fait tellement longtemps que je ne m'en souviens pas.)

    • Il serait this->bar=barre, mais oui.
    • Vous pouvez le faire (même si la syntaxe est un peu différente, comme Kylotan déjà noté), mais si bar est une chaîne de caractères, vous ne voulez pas.
    • l_ locale et a_ pour les arguments ont été utilisés par un de mes anciens collègues. Il fait refactoring un b!tch, car il a fini par produire un delta de presque toutes les lignes, en raison de l'noms.
    • Kylotan: Ma question était à propos de la syntaxe, mais plutôt, serait C++ reconnaître this->barre de référencer la valeur de membre et sans fioritures de la barre en tant que paramètre? Voilà comment cela fonctionne en Java. Ou peut-être que vous avez voulu transmettre que la réponse à cette question est oui.
    InformationsquelleAutor Jay
  12. 0

    Je suis d'accord avec vous que le trait de soulignement variable suffixe n'est pas l'idéal style de codage, et que l'ajout d'un peu de complexité dans le constructeur est mieux que d'ajouter plus de complexité tout au long de l'ensemble de la classe.

    L'autre jour, j'ai pris un coup d'oeil à un de mes vieux projets Java où j'avais appliqué le trait de soulignement suffixe de noms de variables, et j'ai trouvé qu'il n'rendre la lecture du code plus difficile. Il n'était pas trop dur de s'y habituer, mais je l'ai trouvé légèrement distraire sans l'ajout d'aucun avantage réel.

    • Il vous gêne parce que c'est un vieux projet et vous travaillez maintenant avec une autre convention. Le même est vrai pour n'importe quelle convention, lorsque vous changez, vous êtes distrait, jusqu'à ce que vous adapter.
    • Je trouve gênant, car cela ajoute à caractères inutiles à un nom de variable. J'aurais probablement omis le souligne sur ce projet original, mais il a dû utiliser du fait de l'forcé conventions.
    InformationsquelleAutor Kaleb Brasee
  13. 0

    J'ai toujours envie de distinguer les membres de la classe à partir des variables. J'utilise le _ comme préfixe pour les membres et personnellement cela permet de maintenir le code propre et lisible. Les préfixes beau travail avec l'éditeur de l'intellisense. Préfixant avec m_ ou s_ est utile, mais Il semble laid pour moi.

    InformationsquelleAutor thanos.a