web-dev-qa-db-fra.com

Directives de dénomination de champ C #?

Je vais travailler seul sur un peu de code C #, mais je veux m'assurer de respecter les conventions de nommage les plus largement acceptées au cas où je souhaiterais faire appel à d'autres développeurs, publier mon code ou vendre mon code. En ce moment, je suis la convention de nommage que Microsoft a définie car ils semblent être les plus largement acceptés. La seule chose qu'ils ne mentionnent pas, c'est la dénomination des champs privés. Dans la plupart des cas, je les ai vus nommés dans camelCase comme des champs protégés, mais cela pose un problème, car les noms de paramètres doivent être dans camelCase. Prenons par exemple le constructeur suivant:

public GameItem(string baseName, string prefixName, string suffixName)
{
    //initialize code
}

Maintenant, si j'utilise camelCase pour les champs privés aussi, il y a un conflit de noms sauf si j'utilise "this" afin d'accéder aux champs de classe (ce qui, à mon avis, va à l'encontre de la plupart des normes, signifie plus de dactylographie). Une solution consiste à attribuer un nom différent au paramètre, mais cela n’a aucun sens logique de donner deux noms différents aux mêmes données. La seule autre solution que je connaisse qui soit courante dans le codage C++ consiste à donner un soulignement aux membres privés au début (_camelCase). Cette solution est-elle communément acceptée avec le codage C #? Existe-t-il une autre solution à ce problème (utiliser uniquement les propriétés (qui utilisent PascalCase) pour accéder aux champs, même dans la classe elle-même)?

c#naming-conventions
37
ryanzec

Suivez les Microsoft Naming Guidelines . Les instructions pour l’utilisation des champs indiquent qu’il devrait s'agir de camelCase et non d’un préfixe. Notez que la règle générale est sans préfixe; la règle spécifique n'est pas de préfixer pour distinguer les champs statiques des champs non statiques.

N'appliquez pas de préfixe aux noms de champs ni aux noms de champs statiques. En particulier, n'appliquez pas de préfixe à un nom de champ pour distinguer les champs statiques des champs non statiques. Par exemple, appliquer un préfixe g_ ou s_ est incorrect.

et (de Conventions de nommage générales )

N'utilisez pas de traits de soulignement, de traits d'union ni d'autres caractères non alphanumériques.

EDIT: Je noterai que la documentation n'est pas spécifique aux champs private mais indique que les champs protected doivent être uniquement camelCase. Je suppose que vous pouvez en déduire que toute convention relative aux domaines privés est acceptable. Il est certain que les champs statiques publics diffèrent de ceux protégés (ils sont en majuscule). Mon opinion personnelle est que les domaines protégé/privé ne sont pas suffisamment différents pour justifier une convention de nommage différente, d’autant plus que tout ce que vous semblez vouloir faire est de les différencier des paramètres. Autrement dit, si vous suivez les instructions relatives aux champs protégés, vous devrez les traiter différemment à cet égard que les champs privés afin de les distinguer des paramètres. J'utilise this lorsque je fais référence aux membres de la classe au sein de la classe pour clarifier la distinction.

EDIT 2

J'ai adopté la convention utilisée dans mon travail actuel, qui consiste à préfixer les variables d'instance privées par un trait de soulignement et à exposer uniquement les variables d'instance protégées en tant que propriétés utilisant PascalCase (généralement des propriétés automatiques). Ce n’était pas ma préférence personnelle, mais c’est une priorité avec laquelle je me suis habitué et que je suivrai probablement jusqu’à ce que quelque chose de mieux se présente.

35
tvanfosson

_camelCase pour les champs est commun de ce que j'ai vu (c'est ce que nous utilisons chez nous et Microsoft préférez pour .NET Framework ).

Ma justification personnelle pour utiliser cette norme est qu'il est plus facile de taper _ pour identifier un champ privé que this.

Par exemple:

void Foo(String a, String b)
{
    _a = a;
    _b = b;
}

Versus

void Foo(String a, String b)
{
    this.a = a;
    this.b = b;
}

Je trouve le premier beaucoup plus facile à taper et cela m’empêche d’attribuer accidentellement le paramètre appelé a au lieu de this.a. Cette règle est renforcée par une règle Code Analysis Maintainability qui indique:

  • CA1500 Les noms de variables ne doivent pas correspondre aux noms de champs.

Mon autre raison est que this. est optionnel (le resharper vous invite à les supprimer) s'il n'entre pas en conflit avec une variable locale ou un nom de paramètre, ce qui rend plus difficile de savoir quelle variable vous utilisez. Si vous avez un _ au début de tous les champs privés, vous savez toujours lequel est un champ et lequel a une portée locale.

48
DaveShaw

En général, il existe deux méthodes largement utilisées pour nommer les champs (toujours en utilisant camelCase):

Utilisation d'un préfixe de soulignement 

void F(String someValue) {
  _someValue = someValue;
}

Utilisation de this. pour accéder au champ et éviter les conflits de noms 

void F(String someValue) {
  this.someValue = someValue;
}

Personnellement, je préfère le dernier, mais j'utiliserai la convention définie par l'organisation pour laquelle je travaille.

19
Martin Liversage

Dans notre boutique, nous avons lancé notre premier projet C # en utilisant les directives suggérées par Microsoft pour les membres privés, c.-à-d.

camelCaseFieldName

Mais nous avons rapidement rencontré une confusion entre les membres privés et les paramètres, et nous sommes passés à

_camelCaseFieldName

qui a beaucoup mieux fonctionné pour nous.

Un membre privé a généralement un état qui persiste en dehors d'un appel de méthode - le trait de soulignement principal tend à vous le rappeler.

Notez également que l’utilisation de la syntaxe AutoVariable pour les propriétés peut réduire le besoin de champs de sauvegarde privés, c.-à-d.

public int PascalCaseFieldName { get; set;}

Pour un ensemble concis de normes de Nice qui (généralement) suivent les directives des États membres, consultez normes de convention de nommage sur le réseau et normes de programmation --- meilleures pratiques

10
Tom Bushell

Norme de codage C # de Philips Healthcare

MSDN - Eric Gunnerson

Edit: J'utilise le mot clé "this" pour accéder à des membres non statiques en C # et Java.

3
Deniz Acay

Le plus important est de choisir un standard et de le respecter. Découvrez la norme de codage C # d'iDesign à IDesign (c'est un lien sur le côté droit). C'est un excellent document qui couvre des choses comme les directives de nommage. Ils recommandent d'utiliser la casse des chameaux pour les variables locales et les arguments de méthodes.

3
TLiebe

Nous utilisons StyleCop pour forcer la cohérence dans tout notre code. StyleCop est utilisé dans Microsoft applique un ensemble commun de meilleures pratiques pour la présentation, la lisibilité, la maintenabilité et la documentation du code source C #.

Vous pouvez exécuter StyleCop au moment de la construction et le faire générer des avertissements pour les violations de style.

Pour répondre à votre question spécifique, les champs privés doivent être dans camelCase et précédés de "this".

2
John Myczek

Comme il a été mentionné, Les directives de dénomination Microsoft dose not couvrent les champs privés et la dénomination des variables locales. Et vous ne trouvez pas de cohérence au sein même de Microsoft. Si vous générez un modèle de classe ou jetable dans Visual Studio, il créera quelque chose comme:

public MyClass(int value)
{
    this.value = value;
}

ou

private bool disposedValue = false; // To detect redundant calls

protected virtual void Dispose(bool disposing)
{
    if (!disposedValue)
    {
        ...
    }
}

Heureusement, de plus en plus de code a été ouvert par Microsoft, alors jetons un coup d'œil à leur dépôt, par exemple. ASP.NET Core MVC

private readonly IControllerActivator _controllerActivator;
private readonly IControllerPropertyActivator[] _propertyActivators;

Ou .NET Core

private T[] _array;

Vous pouvez dire que ce n'est pas réellement Microsoft, mais .NET Foundation. Très bien, jetons un coup d'œil à Microsoft repos :

private readonly MetricSeries zeroDimSeries;

Mais voici ancienne implémentation de MVC par Microsoft 

private IActionInvoker _actionInvoker;

Donc, il n’ya pas de pratique courante ni de directive officielle concernant la dénomination des champs privés. Choisissez celui que vous préférez et respectez-le.

2
Kosta_Arnorsky

Réponse courte: utilisez _privateField, c’est-à-dire utilisez le trait de soulignement pour les champs privés.

Réponse longue: voilà ...

Il y a très longtemps, Microsoft suggérait d'utiliser camelCase pour les champs. Voir ici . Notez quand ce document a été créé, 10/22/2008. Assez ancien.

La base de code récente de Microsoft représente toutefois une image différente.

  1. Examinez le style de codage C # du référentiel .NET CoreFX github. # 3 est le point en discussion. Voici la partie pertinente

    Nous utilisons _camelCase pour les champs internes et privés et utilisons readonly si possible.

  2. Jetez également un coup d'œil à Style de codage du référentiel Roslyn qui indique spécifiquement qu'il respecte les conventions de .NET CoreFX.
  3. Jetez un autre coup d'œil à la page de contribution standard .NET , qui indique également (du moins pour le moment) de suivre le même guide que .NET CoreFX.
  4. CoreCLR suggère également de suivre le même guide que CoreFX.
  5. Même Winforms repo parle d'utiliser ce même standard.
  6. Je pense en avoir assez dit. Donc, pour conclure, si vous voulez suivre le guide proposé par Microsoft, je pense que vous savez quoi faire; utilisez le trait de soulignement pour les champs privés comme celui-ci: _privateField.

Mon avis: Moi aussi, je préfère personnellement le soulignement pour mes champs privés - le rend très facilement reconnaissable, sans avoir besoin de la variable this.

1
Sнаđошƒаӽ

Conformément aux conventions de dénomination de Microsoft, les champs privés doivent être précédés d’un trait de soulignement.

Par exemple:

private int _myValue;

Bonne chance!

1
Ian P

La convention que j'utilise pour distinguer les variables de classe privées des paramètres de méthode est la suivante:

private string baseName;
private string prefixName;
private string suffixName;

public GameItem(string baseName, string prefixName, string suffixName)
{
    this.baseName = baseName;
    this.prefixName = prefixName;
    this.suffixName = suffixName;
}
1
Dougc

Jetez un coup d'œil à ReSharper. Cela soulignera tous les endroits où vos noms ne sont pas conformes aux directives habituelles et vous pourrez le personnaliser. De plus, il y a bien sûr de nombreuses autres améliorations de la productivité.

0
Carlos

Je fais ça; c'est assez en ligne avec MSDN.

class MyClass : MyBaseClass, IMyInterface
{
    public event EventHandler MyEvent;
    int m_MyField = 1;
    int MyProperty {
        get {
            return m_MyField;
        }
        set {
            m_MyField = value;
        }
    }

    void MyMethod(int myParameter) {
        int _MyLocalVaraible = myParameter;
        MyProperty = _MyLocalVaraible;
        MyEvent(this, EventArgs.Empty);
    }
}

Voici un peu plus de détails: http://jerrytech.blogspot.com/2009/09/simple-c-naming-convention.html

0
Jerry Nixon - MSFT

J'ai fait beaucoup plus avec VB que C #, je suppose donc que je reporte certaines pratiques (préjugés?) De la première à la dernière.

J'aime que les champs privés de propriétés aient un trait de soulignement important - en particulier en C # en raison de la sensibilité à la casse (dont l'idée était de toute façon ça}?) Et je préfixe les variables de module/classe à l'échelle avec "m" aussi bien pour renforcer leur portée.

Si vous n'aimez pas ça, vous êtes vraiment pas comme ça: j'utilise généralement aussi les préfixes de type (sauf pour les champs de propriété) - "o" pour Object, "s" pour String, " i "pour Integer, etc.

Je ne peux pas vraiment défendre cela avec un article évalué par des pairs ou quoi que ce soit, mais cela fonctionne pour nous et signifie que nous ne sommes pas dérangés par la confusion entre les boîtiers ou les champs/paramètres.

Alors ...

Class MyClass

    Private msClassVariable  As String = ""

    Private _classProperty As Integer = 0
    Property Readonly ClassProperty() As Integer
        Get
            Return _classProperty
        End Get
    End Property

    Sub New()

        Dim bLocalVariable As Boolean = False
        if _classProperty < 0 Then _classProperty = 0
        msClassVariable  = _classProperty.ToString()
        bLocalVariable = _classProperty > 0
    End Sub

End Class
0
SteveCinq