Pourquoi ne devrais-je pas préfixer mes champs? [fermé]

https://stackoverflow.com/questions/659552

20-08-2019
|

Question

Je n’ai jamais été fan de la notation hongroise, je l’ai toujours trouvée plutôt inutile si vous ne réalisiez pas une programmation de très bas niveau, mais dans chaque projet C ++, j’ai travaillé sur une sorte de politique de notation hongroise. forcé, et avec cela l'utilisation de certains préfixes 'pas vraiment hongrois' comme m_ pour les champs, s_ pour la statique, g_ pour les globaux, etc.

Bientôt, je réalisai à quel point c'était inutile en C # et commençais progressivement à abandonner toutes mes vieilles habitudes ... mais le truc 'm_'. J'utilise toujours le préfixe m_ dans les champs privés car je trouve très utile de pouvoir distinguer les paramètres, les paramètres locaux et les champs.

La convention de dénomination des champs pour les champs sur MSDN dit que je ne devrais pas, mais il ne dit pas pourquoi (comme les conventions de Google, par exemple, ont généralement tendance à rationaliser leurs prescriptions).

Y a-t-il des raisons pour lesquelles je ne devrais pas le faire ou est-ce seulement une question de style? Si c’est le dernier cas, les préfixes sont-ils généralement considérés comme un mauvais style et puis-je m'attendre à des réactions négatives d'autres personnes travaillant sur la base de code?

La solution

J'aime le préfixe de la barre inférieure pour les champs membres. Généralement, cela me plaît, car ainsi, tous mes champs membres sont affichés par ordre alphabétique avant mes méthodes dans la barre d’assistant en haut de l’écran.

WizardBar

Autres conseils

Quand devriez-vous:

Lorsque les directives de codage de votre projet indiquent que vous devriez

Quand ne devriez-vous pas:

Lorsque les directives de codage de votre projet indiquent que vous ne devriez pas

Si vous n’avez pas encore de directives, vous êtes libre de choisir ce que vous-même ou votre équipe souhaitez et avec lequel vous vous sentez le plus à l’aise. Personnellement, lors du codage en C ++, j'ai tendance à utiliser m_ pour les membres, cela aide. Lors du codage dans d’autres langues, en particulier celles qui n’ont pas de vraies classes (comme Javascript, Lua), ce n’est pas le cas.

En bref, je ne crois pas qu'il existe un & "droit &"; et un " faux " manière.

La fonctionnalité de propriété implémentée automatiquement dans C # 3.0 crée moins de besoins pour cette convention d'une manière ou d'une autre. Au lieu d'écrire

string m_name;
public string Name { get { return m_name; } }

string _Name;
public string Name { get { return _Name; } }

(ou toute autre convention), vous pouvez maintenant écrire

public string Name { get; private set; }

Etant donné que vous n'avez plus besoin de la variable de magasin de sauvegarde explicite, vous n'avez plus besoin de lui attribuer un nom. évitant ainsi toute cette discussion.

Évidemment, cet argument ne s'applique pas lorsque vous avez vraiment besoin d'un magasin de sauvegarde explicite, tel que la validation.

Comme certains l'ont mentionné, les directives des États membres indiquent:

N'utilisez pas de préfixe pour les noms de champs. Par exemple, n’utilisez pas g_ ou s_ pour distinguer statique et non statique champs.

Je suis d'accord avec cela. les préfixes donnent à votre code une apparence laide et gaspillent de l’espace avec des caractères sans conséquence. Cela dit, il est souvent courant d'utiliser des champs pour sauvegarder des propriétés où le champ et la propriété auraient le même nom (le champ privé étant camel case et la propriété étant cascal). En VB, cela ne fonctionne pas, car VB n'est pas sensible à la casse. Dans ce scénario, je recommande l’utilisation d’un seul préfixe _. Ni plus ni moins. Il a juste l’air plus propre, à mon humble avis.

J'ai expérimenté m_, s_, seulement _ et aucun préfixe. J'ai décidé d'utiliser uniquement _ pour toutes les variables statiques et d'instance. Je ne trouve pas important de distinguer les variables statiques des variables d'instance. En théorie, ça sonne bien, dans la pratique, cela ne pose pas de problème.

Un collègue a déjà présenté un argument convaincant pour éliminer tous les préfixes. Nous l’avons essayé sur un projet et cela a fonctionné mieux que prévu. Je l'ai reporté à mon prochain projet et je me suis énervé qu'il & "Interfère &"; avec Intellisense. Lorsque vous avez la situation suivante

int foo;
public int Foo
{
  get { return foo; }
}

Commencer à taper foo suggérera à la fois la variable d’instance et la propriété. Le préfixe de la variable avec un trait de soulignement élimine la double suggestion ennuyeuse. Je suis donc revenu à l’utilisation de _.

J'essaie de suivre les consignes relatives à la bibliothèque MSDN .NET . Ils incluent une consignes de dénomination .

Évidemment, elles sont secondaires aux directives de votre projet.

Je préfère marquer les champs de sauvegarde de propriété (bien que, comme déjà mentionné, .NET 3.0+ réduise le besoin grâce aux propriétés automatiques) avec des traits de soulignement, mais pas le & "; m &" ;. D'une part, il les place en haut de la liste InteliSense lorsque je viens de les utiliser.

Je dois admettre que je dois mettre à jour les directives sur MSDN, les choses peuvent changer si rapidement ces jours-ci.

Avec des outils tels que resharper, il n'y a vraiment aucune raison pour les préfixes. De plus, si vous écrivez des méthodes courtes, vous devriez être capable de dire très rapidement d'où vient le var. Enfin, je suppose que je ne verrais pas vraiment le besoin de faire la différence entre un statique et non pas, car encore une fois, resharper va le marquer si vous essayez de faire quelque chose que vous ne pouvez pas faire. Même sans resharper, le compilateur vous enregistre probablement.

Je préfixe toujours les variables membres avec m _ et les variables statiques avec s _ pour les mêmes raisons que vous avez indiquées. Certaines personnes préfixent les variables membres par un trait de soulignement, mais j’ai toujours trouvé cela un peu étrange (mais c’est une préférence personnelle).

La plupart des gens avec qui je travaille utilisent le préfixe m_ / s_. Je ne pense pas vraiment que ce que vous utilisiez compte autant que vous êtes cohérent.

Je ne les utilise jamais. Il encourage les codes bâclés. Les instructions de codage MSDN, voilà où en sont les choses.

Voici quelques raisons d'utiliser _ (et non m_):

(1) Beaucoup de gars de la BCL le font malgré le guide de nommage de MS. (Découvrez leur blog .) Ces gars écrivent le cadre, ils ont donc de bonnes habitudes mérite d'être copié. Certains des exemples de code les plus utiles sur MSDN sont écrits par eux et utilisent donc la convention de soulignement. C'est une norme de facto de l'industrie.

(2) Un simple trait de soulignement est un moyen à la fois clair et discret de lever l’ambiguïté des variables de méthode et de niveau classe en lisant simplement le code source. Il aide les utilisateurs à comprendre le nouveau (ou l’ancien) code en un coup d’œil lors de sa lecture. Oui, vous pouvez passer la souris sur cet élément pour le voir dans un IDE, mais nous ne devrions pas être obligés de le faire. Vous voudrez peut-être le lire dans un éditeur de texte ou oserai-je le dire sur papier.

(3) Certains disent que vous n'avez pas besoin de préfixe car les méthodes seront courtes, et plus tard, si nécessaire, vous pouvez changer le champ pour une propriété implémentée automatiquement. Mais dans le monde réel, les méthodes sont aussi longues qu’elles sont nécessaires et il existe des différences importantes entre les champs et les propriétés (par exemple, la sérialisation et l’initialisation).

Note de bas de page: le " m " for membre dans m_ est redondant dans notre utilisation ici, mais c'était minuscule car l'une des idées de beaucoup de ces anciennes conventions de nommage était que les noms de type commençaient par des majuscules et les noms d'instance commençant par des minuscules. Cela ne s'applique pas dans .NET, donc c'est redondant. De plus, la notation hongroise était parfois utile avec les anciens compilateurs C (par exemple, le coulage d’entiers ou de pointeurs et l’arithmétique), mais même en C ++, son utilité était réduite lorsqu’il s’agissait de classes.

Il existe une différence importante entre C ++ et le support C #: Tool. Lorsque vous suivez les directives établies (ou leurs variantes courantes), vous obtenez un niveau de support d’outil que C ++ n’a jamais eu. Le respect des normes permet aux outils d'effectuer des opérations de refactoring / changement de nom plus profondes que celles que vous auriez autrement été capable de réaliser. Resharper fait cela. Alors, respectez l’une des normes établies.

Comme @John Kraft le mentionne, il n'y a pas de & "correct &"; réponse. MattJ est le plus proche - vous devriez toujours suivre les directives de style de votre entreprise. Quand à Rome et tout ça.

Pour ce qui est de mon opinion personnelle, comme il est demandé ici, je vote pour que vous laissiez tomber m_.

Je pense que le meilleur style est celui où tous les membres sont PascalCased, quelle que soit leur visibilité (c’est-à-dire même private membres) et où tous les arguments sont camelCased. Je ne casse pas ce style.

Je peux comprendre le désir de préfixer le champ de magasin de sauvegarde de propriété; après tout, vous devez faire la différence entre le terrain et la propriété, non? Je suis d'accord, vous devez. Mais utilisez un post-correctif.

Au lieu de m_MyProperty (ou même de _MyProperty, ce que j'ai vu et même promu autrefois), utilisez MyPropertyValue. Il est plus facile à lire et à comprendre et, plus important encore, à proximité du nom de votre propriété d'origine dans intellisense.

Finalement, c’est la raison pour laquelle je préfère un postfixe. Si je veux accéder à My <down-arrow> <tab> en utilisant intellisense, vous tapez (généralement) & "; MyProperty &" ;, puisque vous êtes alors suffisamment proche pour que seuls m_My <tab> et <=> figurent sur la liste. . Si vous voulez accéder à <=> en utilisant intellisense, vous devrez taper & Quot; <=> & Quot;.

À mon avis, il s’agit d’une économie de frappe au clavier.

Je ne fais jamais cela et la raison en est que je [essaie] de garder mes méthodes courtes. Si je peux voir toute la méthode à l'écran, je peux voir les paramètres, je peux voir les sections locales et ainsi je peux dire ce qui appartient à la classe et ce qui est un paramètre ou un local.

Je nomme généralement mes params et locaux en utilisant une notation particulière, mais pas toujours. Je ne suis rien sinon incohérent. Je m'appuie sur le fait que mes méthodes sont courtes et j'essaie de les empêcher de faire X, Y et Z alors qu'ils ne devraient faire que X.

Quoi qu'il en soit, ce sont mes deux cents.

Sauf si je suis coincé avec vi ou Emacs pour l'édition de code, mon IDE prend en charge l'affichage différentiel des membres pour moi, de sorte que j'utilise rarement des conventions spéciales. Cela vaut également pour préfixer les interfaces avec I ou les classes avec C.

Quelqu'un, veuillez expliquer le style .NET du préfixe I sur les interfaces. :)

Ce à quoi je suis habitué, c'est que les propriétés privées ont un petit soulignement f.ex & "; chaîne _nom &"; le public a " Nom " ;. et les variables d'entrée dans les méthodes ont une petite lettre " void MyMethod (nom de chaîne) ".

si vous avez statique const est souvent écrit en grosses lettres. static const MYCONST = "hmpf".

Je n’utilise jamais de verrues hongroises dès que le choix me est donné. C'est une saisie supplémentaire qui ne transmet aucune information significative. Tout bon IDE (et je définis & "; Bien &" En fonction de la présence de cette fonctionnalité, entre autres) vous permettra d’avoir une coloration syntaxique différente pour les membres statiques, les membres d’instance, les fonctions membres, les types, etc. Il n’ya aucune raison de surcharger votre code d’informations pouvant être fournies par l’EDI. Ceci est un corollaire pour ne pas encombrer votre code d'ancien code commenté, car votre système de gestion de versions devrait en être responsable.

Le meilleur moyen est de convenir d’une norme avec vos collègues et de vous y tenir. Ce n’est pas nécessairement la méthode qui conviendra le mieux à tout le monde, il est plus important que de s’entendre sur une méthode plutôt que sur la méthode sur laquelle vous êtes réellement d'accord.

Ce que nous avons choisi pour notre code standard est d’utiliser _ comme préfixe pour les variables membres. L’une des raisons était qu’il était facile de trouver les variables locales dans l’intellisense.

Avant de nous mettre d’accord sur cette norme, j’en ai utilisé une autre. Je n'ai utilisé aucun préfixe et j'ai écrit this.memberVariable dans le code pour montrer que j'utilisais une variable membre.

Avec la propriété abrégée en C # 3, je constate que j'utilise beaucoup moins de variables de membre explicites.

Ce qui se rapproche le plus des directives officielles est StyleCop , un outil de Microsoft permettant d'analyser automatiquement vos fichiers source et détectez les violations du style de codage recommandé. Ils peuvent être exécutés à partir de Visual Studio et / ou de versions automatisées telles que MSBuild.

Nous l'utilisons dans nos projets et cela contribue à rendre le style et la mise en code du code plus cohérent entre les développeurs, même si cela prend plutôt un peu de temps pour s'y habituer!

Pour répondre à votre question, elle ne permet aucune notation en hongrois, ni aucun préfixe tel que m_ (en fait, elle ne permet pas du tout d'utiliser des traits de soulignement).

Je n'utilise plus ce style. Il a été développé pour vous aider à voir rapidement comment les variables ont été utilisées. Les environnements de développement les plus récents vous permettent de voir ces informations en plaçant votre souris sur la variable. Si vous utilisez ces nouveaux outils, vous n’en aurez plus besoin.

Les normes de codage C ++ ( Sutter, Herb et Alexandrescum Andrei , 2004) pourraient également nous éclairer. Le point 0 s'intitule & "Ne pas faire transpirer les petites choses." (Ou: savoir quoi ne pas normaliser.) & ";

Ils abordent un peu cette question en disant & "Si vous ne pouvez pas choisir votre propre convention de nommage, essayez ... variables de membre privées likeThis _ ... < !> quot; (Rappelez-vous que l'utilisation du tiret bas est soumise à des règles très spécifiques en C ++).

Cependant, avant d’y arriver, ils insistent sur un certain niveau de cohérence & "; l’important n’est pas de définir une règle, mais bien d’être cohérent avec le style déjà utilisé dans le fichier ... "

L'avantage de cette notation en C / C ++ était de permettre de voir plus facilement le type d'un symbole sans avoir à rechercher la déclaration. Ces styles sont apparus avant l’arrivée d’Intellisense et de & «Aller à la définition &»; - nous devions souvent nous lancer à la chasse aux oies pour trouver la déclaration indiquant qui sait combien de fichiers d'en-tête. Sur un projet de grande envergure, cela pourrait être une gêne importante, ce qui était déjà assez grave lorsque vous examiniez le code source C, mais encore pire lorsque vous menez une expertise judiciaire en utilisant un assemblage mixte + code source et une pile d'appels bruts.

Face à ces réalités, l’utilisation de m_ et de toutes les autres règles hongroises commence à avoir un sens, même avec le temps système nécessaire à la maintenance, en raison du temps que cela économiserait en regardant simplement le type de symbole lorsqu’il s’agit de code inconnu. Maintenant, bien sûr, nous avons Intellisense et & "Aller à la définition &"; La motivation principale de cette convention de nommage n’existe donc plus. Je ne pense pas qu'il soit plus utile de le faire, et j'essaie généralement de suivre les directives de la bibliothèque .NET juste pour être cohérent et éventuellement obtenir un peu plus de prise en charge des outils.

Je suis sûr que je vais être flambé pour cela, mais ainsi soit-il.

C’est ce qu’on appelle les directives de la bibliothèque .NET de Microsoft, mais c’est vraiment Les vues de Brad Abrams ( document ici ) - il existe d'autres vues avec des raisons valides.

Les gens ont tendance à adhérer à l'opinion de la majorité plutôt que d'avoir de bonnes raisons pour un style spécifique.

Le point important est d’évaluer pourquoi un style spécifique est utilisé et pourquoi il est préféré à un autre style - en d’autres termes, justifiez votre choix de style non seulement parce que tout le monde dit que c’est la chose à faire: pensez par vous-même.

La raison fondamentale pour ne pas utiliser le hongrois à l'ancienne était l'utilisation d'abréviations différentes pour chaque équipe et difficiles à maîtriser. Il est facile de résoudre ce problème en n'abréviant pas.

Au fur et à mesure que les outils de développement disponibles changent, le style doit changer pour donner le sens le plus logique - mais il existe une bonne raison pour chaque élément de style.

Vous trouverez ci-dessous les directives de mon style et mes raisons. Je cherche toujours des moyens d’améliorer mon style pour créer du code plus fiable et plus facile à gérer.

Convention de dénomination des variables

Nous avons tous notre point de vue sur les conventions de dénomination des variables. Il existe de nombreux styles différents qui aideront à produire un code de qualité facilement maintenable - tout style prenant en charge les informations essentielles de base d'une variable est correct. Les critères pour une convention de dénomination spécifique doivent être qu’elle aide à produire un code fiable et facilement maintenable. Les critères à ne pas utiliser sont les suivants: C'est moche Microsoft (c'est-à-dire Brad Abrams) dit de ne pas utiliser ce style - Microsoft ne produit pas toujours le code le plus fiable, il suffit de regarder les bogues dans Expression Blend. Lors de la lecture du code, il est très important qu'un nom de variable transmette instantanément trois faits essentiels sur la variable: sa portée! & # 8217; s c'est & # 8217; le type clairement comprendre à quoi il sert Portée: Microsoft recommande de s’appuyer totalement sur IntelliSense. IntelliSense est génial. Cependant, il ne faut tout simplement pas survoler chaque variable pour voir sa portée et son type. Supposer qu'une variable est dans une portée qui ne l'est pas peut provoquer des erreurs significatives. Par exemple, si une variable de référence est transmise en tant que paramètre et modifiée dans la portée locale, cette modification sera conservée après le retour de la méthode, ce qui risque de ne pas être souhaité. Si un champ ou une variable statique est modifié dans la portée locale mais que l'on pense que c'est une variable locale, un comportement inattendu pourrait en résulter. Par conséquent, il est extrêmement important de pouvoir simplement regarder une variable (pas avec la souris) et de connaître instantanément sa portée.

Le style suivant pour indiquer la portée est suggéré; cependant, n'importe quel style convient parfaitement tant qu'il indique clairement et systématiquement la portée de la variable: m_ variable de champ paramètre p_ transmis à une méthode s_ variable statique variable locale Type: de graves erreurs peuvent se produire si l’on pense qu’ils travaillent avec un type spécifique alors qu’ils travaillent réellement avec un type différent - encore une fois, nous ne survolons simplement aucune variable pour déterminer son type, nous supposons simplement que nous savons de quel type il correspond. est et c'est comment les erreurs sont créées.

Abréviations: Les abréviations sont diaboliques car elles peuvent signifier différentes choses pour différents développeurs. Un développeur peut penser qu’un minuscule & Quot; s & Quot; signifie chaîne alors qu'un autre peut penser que cela signifie un entier signé. Les abréviations sont un signe de codage paresseux. Prenez un peu de temps supplémentaire et tapez le nom complet pour que le développeur sache clairement le conserver. Par exemple, la différence entre & "; Str &"; et " chaîne " est seulement trois caractèresCela ne prend pas beaucoup plus d’efforts pour rendre le code facile à gérer.

Les abréviations courantes et claires pour les types de données intégrés uniquement sont acceptables mais doivent être normalisées au sein de l'équipe.

Code auto-documentant: L'ajout d'une description claire à un nom de variable facilite la lecture et la compréhension du code par un autre développeur. Rendez le nom si compréhensible que le responsable de l'équipe puisse lire et comprendre le code sans être un développeur. / p>

Ordre des parties de nom de variable: L'ordre recommandé est description de type d'étendue, car: IntelliSense regroupera toutes les portées similaires et, à l'intérieur de chaque portée, IntelliSense groupera tous les types similaires, ce qui facilitera les recherches. Essayez de rechercher une variable dans l'autre sens. Il est très facile de voir et de comprendre la portée et de voir et de comprendre le type C'est un style assez commun et facile à comprendre Il passera FxCop

Exemples: Voici quelques exemples: m_stringCustomerName p_stringCustomerDatabaseConnectionString intNumberOfCustomerRecords ou iNumberOfCustomerRecords ou entierNumberOfCustomerRecords Ces règles simples amélioreront considérablement la fiabilité et la maintenabilité du code.

Instructions de ligne unique de la structure de contrôle Toutes les structures de contrôle (si, tant que, etc.) les instructions de ligne unique doivent toujours être entourées d'accolades car il est très facile d'ajouter une nouvelle instruction sans se rendre compte qu'une instruction donnée appartient à une structure de contrôle qui rompra la logique du code sans générer des erreurs de compilation.

Habillage des exceptions de méthode Toutes les méthodes doivent être emballées avec un piège externe try-catch, fournir un emplacement pour récupérer, identifier, localiser, enregistrer et prendre la décision de lancer ou non. C’est l’exception inattendue qui provoque le blocage de nos applications - en encapsulant chaque méthode pour capturer toutes les exceptions non gérées, nous garantissons l’identification et la journalisation de toutes les exceptions et nous empêchons notre application de planter. Il faut un peu plus de travail mais les résultats en valent la peine.

Indentation L'indentation n'est pas un problème majeur. cependant, quatre espaces et ne pas utiliser d'onglets sont suggérés. Si du code est imprimé, le premier onglet de l’imprimante a généralement 8 espaces par défaut. Différents développeurs ont tendance à utiliser différentes tailles d'onglets. Le code de Microsoft est généralement mis en retrait de 4 espaces. Par conséquent, si vous utilisez un code Microsoft et utilisez des espaces autres que 4, le code devra être reformaté. Quatre espaces le rendent facile et cohérent.

Si vous ne codez pas conformément à une directive particulière, vous devez continuer à utiliser votre notation m_ actuelle et à la modifier si les instructions de codage du projet l'indiquent.

Soyez fonctionnel.

N'utilisez pas de variables globales.
N'utilisez pas de variables statiques.
N'utilisez pas de variables membres.

Si vous devez le faire, mais uniquement si vous le devez vraiment, utilisez une et une seule variable pour accéder à votre application / votre environnement.

Licencié sous: CC-BY-SA avec attribution

Non affilié à StackOverflow