Quel type de préfixe utilisez-vous pour les variables membres?

Question

Pas de doute, il est essentiel pour la compréhension du code pour les variables d'un préfixe, afin qu'ils puissent être facilement distingué de "normal" des variables.

Mais ce type de préfixe utilisez-vous?

J'ai travaillé sur des projets où nous avons utilisé m_ en tant que préfixe, sur d'autres projets, nous avons utilisé un trait de soulignement (qui personnellement, je n'aime pas, car un trait de soulignement n'est pas assez démonstratif).

Sur un autre projet, nous avons utilisé un long préfixe de la forme, qui comprenait également le type de variable. mul_ , par exemple, est le préfixe d'un membre de la variable de type unsigned long.

Permettez-moi maintenant de savoir quel type de préfixe que vous utilisez (et s'il vous plaît donner une raison à cela).

EDIT: la Plupart d'entre vous semblent code sans les préfixes pour les variables de membre de! Fait cela dépend de la langue? De mon expérience, de code C++ a tendance à utiliser un trait de soulignement ou m_ comme préfixe pour les variables de membre. Quelles sont les autres langues?

Answer 1

Pas de doute, il est essentiel pour la compréhension du code pour les variables d'un préfixe, afin qu'ils puissent être facilement distingué de "normal" des variables.

Je contester cette demande. Ce n'est pas le moins du monde nécessaire si vous avez une demi-décent de la syntaxe. Une bonne IDE peuvent vous permettre d'écrire votre code en anglais lisible, et peut vous montrer le type et la portée d'un symbole de d'autres façons. Eclipse est un bon travail en mettant en évidence les déclarations et les usages d'un symbole lorsque le point d'insertion est sur l'un d'eux.

Edit, merci slim: Une bonne syntaxe surligneur comme Eclipse vous permettra aussi d'utiliser les caractères gras ou en italique du texte, ou de changer de police de caractères au total. Par exemple, j'aime les italiques pour les choses statiques.

Un autre edit: Pensez-y de cette façon; le type et la portée d'une variable sont des informations secondaires. Il devrait être disponible et facile à trouver, mais pas crié à vous. Si vous utilisez des préfixes comme m_ ou des types comme LPCSTR, qui devient de bruit, quand vous voulez juste de lire l'information primaire – l'intention du code.

Troisième edit: Ceci s'applique indépendamment de la langue.

Answer 2

Je ne pas utiliser un préfixe à tous. Si je suis en danger de mélanger des variables locales ou des paramètres de la méthode avec les membres de la classe, soit la méthode de la classe est trop long et les avantages de la séparation.

Cette (sans doute), non seulement rend le code plus lisible et un peu "fluent", mais le plus important encourage bien structuré, des classes et des méthodes. En fin de compte, il se résume à un tout autre problème que le préfixe ou pas de préfixe de problème pour.

Mise à JOUR: eh bien, le goût et les préférences de changement, n'est-ce pas.. je vais maintenant utiliser le trait de soulignement comme préfixe pour les variables de membre comme elle s'est révélée être bénéfique dans la reconnaissance locale et membre de variables dans le long terme. En particulier les nouveaux membres de l'équipe ont parfois dur de temps, quand les deux ne sont pas facilement reconnaissables.

Answer 3

Aucun. J'avais l'habitude d'utiliser le trait de soulignement, mais j'en ai parlé sur un projet où les autres ne l'aimaient pas et ne l'avaient pas manqué. Un IDE décent ou une mémoire décente vous dira ce qu’est une variable membre et ce qui ne l’est pas. L'un des développeurs de notre projet insiste pour mettre "ceci". devant chaque variable de membre, et nous l’amusons lorsque nous travaillons sur des zones de code qui sont nominalement "ses".

Answer 4

Souligner seulement.

Dans mon cas, je l'utilise parce que c'est ce que dit le document sur les normes de codage sur mon lieu de travail. Cependant, je ne vois pas l'intérêt d'ajouter m_ ou quelque chose d'horrible en hongrois au début de la variable. Le mimimaliste 'undercore only' reste lisible.

Answer 5

Il est plus important d'être cohérent que quoi que ce soit, afin de choisir quelque chose que vous et vos coéquipiers peuvent se mettre d'accord et de s'y tenir. Et si la langue que vous codez en a une convention, vous devriez essayer de s'y tenir. Rien n'est plus déroutant que d'une base de code qui suit une préfixation de la règle de façon incohérente.

Pour le c++, il y a une autre raison de préférer m_ plus _ outre le fait qu' _ parfois préfixes compilateur de mots clés. Le m est synonyme de variable membre. Cela vous donne également la possibilité de supprimer l'ambiguïté entre les habitants et les autres catégories de variables, s_ statique et g_ mondiale (mais, bien sûr, ne pas utiliser de variables globales).

Comme pour les commentaires que l'IDE va toujours prendre soin de vous, c'est l'IDE vraiment la seule façon que vous êtes en train de regarder votre code? Est-ce que votre outil de comparaison ont le même niveau de qualité de sa mise en surbrillance de la syntaxe que de l'IDE? Quelle est votre source de contrôle de l'historique de la révision de l'outil? Avez-vous jamais même chat un fichier source à la ligne de commande? IDE moderne du fantastique, de l'efficacité des outils, mais le code doit être facile à lire quel que soit le contexte, vous êtes en train de lire dans.