Pourquoi devrais-je (ou ne devrais-je) pas préfixer les champs avec "m_" en C #?

Question

J'ai été un programmeur C++ pour près de 12 ans maintenant. Quand j'ai déménagé à la C# il y a deux ans j'ai apporté avec moi le même style de codage, j'ai été tellement habitués à. Bientôt, j'ai réalisé combien il était inutile en C# et a progressivement commencé à laisser tomber tous mes habitudes... mais le 'm_' chose.

Je n'ai jamais été un fan de la notation hongroise, j'ai toujours trouvé ça assez inutile, sauf si vous êtes en train de faire vraiment de la programmation de bas niveau, mais dans chaque projet C++, j'ai travaillé sur une sorte de notation hongroise politique a été appliquée, et avec elle, l'utilisation de quelques "pas-vraiment-hongrois" préfixes comme m_ pour les champs, s_ pour la statique, g_ pour les variables globales et ainsi de suite.

Maintenant, je continue à utiliser le m_ préfixe sur les champs privés parce que je trouve vraiment très utile d'être capable de distinguer entre les params, des habitants et des champs, mais quelque chose dans le dos de ma tête me dit que je suis en train de faire du C++.

J'aimerais entendre vos avis afin que je puisse enfin se décider laquelle est la "meilleure façon",

Merci.

Answer 1

J'aime le préfixe underbar pour les champs membres. La plupart du temps, je l’aime bien, 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.

Answer 2

Lorsque vous devez:

• Lorsque votre projet de directives de codage dire que vous devriez

Lorsque vous ne devriez pas:

• Lorsque votre projet de directives de codage dire que vous ne devriez pas

Si vous n'avez pas de lignes directrices encore, vous êtes libre de choisir ce que vous ou votre équipe voulez et à se sentir plus à l'aise avec. Personnellement, lorsque le codage C++ j'ai tendance à utiliser m_ pour les membres, il ne l'aide. Lors du codage dans d'autres langues, en particulier ceux sans véritable classes (comme en Javascript, Lua) je n'ai pas.

En bref, je ne crois pas qu'il existe un "droit" et une "mauvaise" façon.

Answer 3

L'auto-mise en œuvre de la propriété fonctionnalité de C# 3.0 crée de moins en moins besoin de cette convention, d'une manière ou l'autre. Au lieu d'écrire

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

ou

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

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

public string Name { get; private set; }

Puisque vous n'avez plus besoin de l'accord explicite magasin variable, vous n'avez plus à trouver un nom pour elle, évitant ainsi toute la discussion.

Évidemment, cet argument ne s'applique pas lorsque vous en avez vraiment besoin explicite de mémoire de sauvegarde comme pour effectuer la validation.

Answer 4

J'essaie de suivre les directives de la bibliothèque MSDN .NET . Ils incluent une section de directives de nommage .

De toute évidence, celles-ci sont secondaires aux directives de votre projet.

Answer 5

Je préfère marquer les champs de sauvegarde des propriétés (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.

J'admets que je dois mettre à jour les directives sur MSDN, les choses peuvent changer si rapidement de nos jours.