Ordre des éléments dans les classes: champs, propriétés, constructeurs, méthodes

Existe-t-il une directive officielle C # pour l'ordre des éléments en termes de structure de classe?

Est-ce que ça va:

• Champs publics
• Champs privés
• Propriétés
• Constructeurs
• Méthodes
  ?

Je suis curieux de savoir s'il existe une règle stricte et rapide sur l'ordre des articles? Je suis un peu partout. Je veux m'en tenir à une norme particulière pour pouvoir le faire partout.

Le vrai problème est que mes propriétés plus complexes finissent par ressembler beaucoup à des méthodes et elles se sentent déplacées au sommet avant le constructeur.

Des conseils / suggestions?

Selon la documentation des règles StyleCop, la commande est la suivante.

Au sein d'une classe, d'une structure ou d'une interface: (SA1201 et SA1203)

• Champs constants
• Des champs
• Constructeurs
• Finaliseurs (destructeurs)
• Délégués
• Événements
• Enums
• Interfaces ( implémentations d'interfaces )
• Propriétés
• Indexeurs
• Les méthodes
• Structs
• Des classes

Au sein de chacun de ces groupes, commandez par accès: (SA1202)

• Publique
• interne
• intérieur protégé
• protégé
• privé

Dans chacun des groupes d'accès, triez par ordre statique, puis non statique: (SA1204)

• statique
• non statique

Dans chacun des groupes de champs statiques / non statiques, triez en lecture seule, puis en lecture seule: (SA1214 et SA1215)

• lecture seulement
• non en lecture seule

Une liste déroulée comporte 130 lignes, donc je ne la déroulerai pas ici. La partie méthodes déroulée est:

• méthodes statiques publiques
• méthodes publiques
• méthodes statiques internes
• méthodes internes
• méthodes statiques internes protégées
• méthodes internes protégées
• méthodes statiques protégées
• méthodes protégées
• méthodes statiques privées
• méthodes privées

La documentation note que si l'ordre prescrit ne convient pas - par exemple, plusieurs interfaces sont mises en œuvre et que les méthodes et propriétés d'interface doivent être regroupées -, utilisez ensuite une classe partielle pour regrouper les méthodes et propriétés associées.

Plutôt que de regrouper par visibilité ou par type d'élément (champ, propriété, méthode, etc.), que diriez-vous de regrouper par fonctionnalité?

C'est une question ancienne mais toujours très pertinente, alors j'ajouterai ceci: Quelle est la première chose que vous recherchez lorsque vous ouvrez un fichier de classe que vous avez peut-être lu ou non auparavant? Des champs? Propriétés? J'ai réalisé par expérience que je vais presque toujours à la recherche des constructeurs, car la chose la plus fondamentale à comprendre est la façon dont cet objet est construit.

Par conséquent, j'ai commencé à placer les constructeurs en premier dans les fichiers de classe, et le résultat a été psychologiquement très positif. La recommandation standard de mettre les constructeurs après un tas d'autres choses semble dissonante.

La fonctionnalité de constructeur principal à venir dans C # 6 fournit la preuve que la place naturelle pour un constructeur est tout en haut d'une classe - en fait, les constructeurs principaux sont spécifiés avant même l'accolade ouverte.

C'est drôle à quel point une réorganisation comme celle-ci fait la différence. Cela me rappelle comment les usinginstructions étaient auparavant ordonnées - avec les espaces de noms System en premier. La commande "Organiser les utilisations" de Visual Studio a utilisé cet ordre. Maintenant, les usings sont simplement classés par ordre alphabétique, sans traitement spécial pour les espaces de noms System. Le résultat semble plus simple et plus propre.

Je ne connais pas de langage ou de norme industrielle, mais j'ai tendance à mettre les choses dans cet ordre avec chaque section enveloppée dans une # région:

à l'aide d'instructions

Espace de noms

Classe

Membres privés

Propriétés publiques

Constructeurs

Méthodes publiques

Méthodes privées

Je recommanderais d'utiliser les normes de codage d' IDesign ou celles répertoriées sur le site Web de Brad Abram . Ce sont les deux meilleurs que j'ai trouvés.

Brad dirait ...

Les membres des classes doivent être classés par ordre alphabétique et regroupés en sections (champs, constructeurs, propriétés, événements, méthodes, implémentations d'interface privée, types imbriqués)

Comme mentionné précédemment, il n'y a rien dans le langage C # qui dicte la disposition, j'utilise personnellement les régions et je fais quelque chose comme ça pour une classe moyenne.

public class myClass
{
#region Private Members

#endregion
#region Public Properties

#endregion

#region Constructors

#endregion
#region Public Methods

#endregion
}

Cela a du sens pour moi de toute façon

De StyleCop

champs privés, champs publics, constructeurs, propriétés, méthodes publiques, méthodes privées

Comme StyleCop fait partie du processus de construction MS, vous pouvez voir cela comme une norme de facto

Habituellement, j'essaie de suivre le modèle suivant:

• membres statiques (ont généralement un autre contexte, doivent être thread-safe, etc.)
• membres d'instance

Chaque partie (statique et instance) se compose des types de membres suivants:

• opérateurs (sont toujours statiques)
• champs (initialisés avant les constructeurs)
• constructeurs
• destructeur ( est une tradition de suivre les constructeurs )
• Propriétés
• les méthodes
• événements

Ensuite, les membres sont triés par visibilité (du moins au plus visible):

• privé
• interne
• interne protégé
• protégé
• Publique

L'ordre n'est pas un dogme: les classes simples sont plus faciles à lire, cependant, les classes plus complexes nécessitent un groupement spécifique au contexte.

Ma préférence est de commander par type, puis de diminuer la visibilité comme suit

public methods
public events
public properties

protected methods
protected events
protected properties

private methods
private events
private properties
private fields

public delegates
public interfaces
public classes
public structs

protected delegates
protected interfaces
protected classes
protected structs

private delegates
private interfaces
private classes
private structs

Je sais que cela viole Style Cop et si quelqu'un peut me donner une bonne raison pour laquelle je devrais placer les détails d'implémentation d'un type avant son interface, je suis prêt à changer. À l'heure actuelle, j'ai une forte préférence pour la priorité des députés.

Remarque: je n'utilise pas de champs publics ou protégés.

Le plus proche que vous trouverez probablement est "Design Guidelines, Managed code and the .NET Framework" ( http://blogs.msdn.com/brada/articles/361363.aspx ) de Brad Abrams

De nombreuses normes sont décrites ici. La section pertinente est 2.8 je pense.

les seules directives de codage que j'ai vues suggérées pour cela sont de mettre les champs en haut de la définition de classe.

j'ai tendance à mettre les constructeurs à côté.

mon commentaire général serait que vous devriez vous en tenir à une classe par fichier et si la classe est assez grande pour que l'organisation des propriétés par rapport aux méthodes soit un gros problème, quelle est la taille de la classe et devriez-vous la refactoriser quand même? représente-t-il de multiples préoccupations?

Je préfère mettre les champs privés en haut avec le ou les constructeurs, puis mettre les bits d'interface publique après cela, puis les bits d'interface privée.

De plus, si la définition de votre classe est suffisamment longue pour que la commande d'articles soit importante, c'est probablement une odeur de code indiquant que votre classe est trop volumineuse et complexe et que vous devriez refactoriser.

Je le garde aussi simple que possible (pour moi au moins)

Énumérations
Déclarations
Constructeurs
Remplace les
méthodes
Propriétés
Gestionnaire d'événements

Il n'y a certainement rien dans le langage qui l'impose en aucune façon. J'ai tendance à grouper les choses par visibilité (publique, puis protégée, puis privée) et à utiliser #regions pour grouper fonctionnellement les choses liées, qu'il s'agisse d'une propriété, d'une méthode ou autre. Les méthodes de construction (qu'il s'agisse de cteurs réels ou de fonctions statiques d'usine) sont généralement en tête de liste, car elles sont la première chose que les clients doivent savoir.

Je sais que c'est vieux mais ma commande est la suivante:

dans l'ordre public, protégé, privé, interne, abstrait

• Constantes
• Variables statiques
• Des champs
• Événements
• Constructeur (s)
• Les méthodes
• Propriétés
• Délégués

J'aime aussi écrire des propriétés comme celle-ci (au lieu de l'approche raccourcie)

// Some where in the fields section
private int someVariable;

// I also refrain from
// declaring variables outside of the constructor

// and some where in the properties section I do
public int SomeVariable
{
    get { return someVariable; }
    set { someVariable = value; }
}