Ordine delle voci nelle classi: campi, proprietà, costruttori, metodi

StackOverflow https://stackoverflow.com/questions/150479

  •  02-07-2019
  •  | 
  •  

Domanda

Esiste una linea guida C # ufficiale per l'ordine degli oggetti in termini di struttura della classe?

Va ??bene:

  • Campi pubblici
  • Campi privati ??
  • Proprietà
  • Costruttori
  • Metodi
    ?

Sono curioso di sapere se esiste una regola rigida e rapida sull'ordine degli articoli? Sono un po 'dappertutto. Voglio attenermi a uno standard particolare in modo da poterlo fare ovunque.

Il vero problema è che le mie proprietà più complesse finiscono per assomigliare molto ai metodi e si sentono fuori posto nella parte superiore davanti al costruttore.

Eventuali suggerimenti / suggerimenti?

È stato utile?

Soluzione

Secondo la Documentazione sulle regole di StyleCop l'ordinamento è il seguente.

All'interno di una classe, struttura o interfaccia: (SA1201 e SA1203)

  • Campi costanti
  • Campi
  • Costruttori
  • Finalizzatori (distruttori)
  • I delegati
  • Eventi
  • Enums
  • Interfacce ( implementazioni dell'interfaccia )
  • Proprietà
  • indicizzatori
  • Metodi
  • Structs
  • Corsi

All'interno di ciascuno di questi gruppi ordina per accesso: (SA1202)

  • pubblico
  • interno
  • interno protetto
  • protetto
  • privati ??

All'interno di ciascuno dei gruppi di accesso, ordina per statico, quindi non statico: (SA1204)

  • static
  • non statico

All'interno di ciascuno dei gruppi di campi statici / non statici, ordina per sola lettura, quindi non sola lettura: (SA1214 e SA1215)

  • in sola lettura
  • non in sola lettura

Un elenco non srotolato è lungo 130 righe, quindi non lo srotolerò qui. La parte dei metodi srotolata è:

  • metodi statici pubblici
  • metodi pubblici
  • metodi statici interni
  • metodi interni
  • metodi statici interni protetti
  • metodi interni protetti
  • metodi statici protetti
  • metodi protetti
  • metodi statici privati ??
  • metodi privati ??

La documentazione osserva che se l'ordine prescritto non è adatto - diciamo, vengono implementate più interfacce e i metodi e le proprietà dell'interfaccia devono essere raggruppati insieme - quindi utilizzare una classe parziale per raggruppare i metodi e le proprietà correlati.

Altri suggerimenti

Invece di raggruppare per visibilità o per tipo di elemento (campo, proprietà, metodo, ecc.), che ne dici di raggruppare per funzionalità?

Questa è una domanda vecchia ma ancora molto rilevante, quindi aggiungerò questa: qual è la prima cosa che cerchi quando apri un file di classe che potresti aver letto o meno? I campi? Proprietà? Mi sono reso conto per esperienza che quasi invariabilmente vado a caccia di costruttori, perché la cosa più semplice da capire è come è costruito questo oggetto.

Pertanto, ho iniziato a mettere i costruttori al primo posto nei file di classe e il risultato è stato psicologicamente molto positivo. La raccomandazione standard di mettere i costruttori dopo un mucchio di altre cose sembra dissonante.

L'imminente funzione di costruttore primario in C # 6 fornisce la prova che il posto naturale per un costruttore è in cima a una classe - in effetti i costruttori primari sono specificati anche prima del controvento aperto.

È divertente quanta differenza fa un riordino come questo. Mi ricorda come venivano ordinate le istruzioni using , prima con gli spazi dei nomi di sistema. Visual Studio " Organizza Usings " il comando ha usato questo ordine. Ora i usando sono ordinati in ordine alfabetico, senza alcun trattamento speciale riservato agli spazi dei nomi di sistema. Il risultato sembra più semplice e più pulito.

Vorrei raccomandare di utilizzare gli standard di codifica da IDesign o quelli elencati nel il sito Web di Brad Abram . Questi sono i due migliori che ho trovato.

Brad direbbe ...

  

I membri delle classi devono essere alfabetizzati e raggruppati in sezioni (campi, costruttori, proprietà, eventi, metodi, implementazioni dell'interfaccia privata, tipi nidificati)

Non conosco un linguaggio o uno standard industriale, ma tendo a mettere le cose in questo ordine con ogni sezione racchiusa in una #regione:

utilizzo delle dichiarazioni

Namespace

Class

Membri privati ??

Proprietà pubbliche

Costruttori

Metodi pubblici

Metodi privati ??

Come accennato prima, non c'è nulla nel linguaggio C # che detta il layout, io personalmente uso le regioni e faccio qualcosa del genere per una classe media. 

public class myClass
{
#region Private Members

#endregion
#region Public Properties

#endregion

#region Constructors

#endregion
#region Public Methods

#endregion
}

Per me ha comunque senso

Da StyleCop

campi privati, campi pubblici, costruttori, proprietà, metodi pubblici, metodi privati ??

Poiché StyleCop fa parte del processo di compilazione di MS, è possibile vederlo come standard di fatto

Di solito provo a seguire il modello successivo:

  • membri statici (di solito hanno un altro contesto, devono essere thread-safe, ecc.)
  • membri dell'istanza

Ogni parte (statica e istanza) è composta dai seguenti tipi di membri:

  • operatori (sono sempre statici)
  • campi (inizializzati prima dei costruttori)
  • costruttori
  • destructor ( è una tradizione seguire i costruttori )
  • proprietà
  • Metodi
  • eventi

Quindi i membri vengono ordinati in base alla visibilità (da meno a più visibile):

  • privati ??
  • interno
  • interno protetto
  • protetto
  • pubblico

L'ordine non è un dogma: le classi semplici sono più facili da leggere, tuttavia, le classi più complesse richiedono un raggruppamento specifico per contesto.

Il più vicino che potresti trovare è " Linee guida di progettazione, codice gestito e .NET Framework " ( http://blogs.msdn.com/brada/articles/361363.aspx) di Brad Abrams

Qui sono descritti molti standard. La sezione pertinente è 2.8 penso.

La mia preferenza è ordinare per tipo e quindi diminuire la visibilità come segue 

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

So che questo viola Style Cop e se qualcuno può darmi una buona ragione per cui dovrei mettere i dettagli di implementazione di un tipo prima della sua interfaccia, sono disposto a cambiare. Al momento, ho una forte preferenza a mettere per ultimo i membri privati.

Nota: non utilizzo campi pubblici o protetti.

le uniche linee guida di codifica che ho visto suggerire per questo sono mettere i campi in cima alla definizione della classe.

tendo a mettere i costruttori accanto.

il mio commento generale sarebbe che dovresti attenersi a una classe per file e se la classe è abbastanza grande da rendere grande l'organizzazione delle proprietà rispetto ai metodi, quanto è grande la classe e dovresti comunque effettuare il refactoring? rappresenta molteplici preoccupazioni?

Preferisco mettere i campi privati ??in alto insieme ai costruttori, quindi inserire i bit dell'interfaccia pubblica dopo quello, quindi i bit dell'interfaccia privata.

Inoltre, se la definizione della tua classe è abbastanza lunga perché l'ordinamento degli articoli contenga molto, è probabilmente un odore di codice indicando che la tua classe è troppo voluminosa e complessa e dovresti fare il refactoring.

Lo mantengo il più semplice possibile (almeno per me)

enumerazioni
dichiarazioni
Costruttori
Sostituzioni
metodi
proprietà
Gestore di eventi

Non c'è certamente nulla nella lingua che lo imponga in alcun modo. Tendo a raggruppare le cose in base alla visibilità (pubblica, quindi protetta, quindi privata) e uso #regioni per raggruppare le cose correlate funzionalmente, indipendentemente dal fatto che si tratti di una proprietà, metodo o altro. I metodi di costruzione (che si tratti di agenti reali o di funzioni statiche di fabbrica) sono in genere al top poiché sono la prima cosa che i clienti devono sapere.

So che questo è vecchio ma il mio ordine è il seguente:

in ordine di pubblico, protetto, privato, interno, astratto

  • Costanti
  • Variabili statiche
  • Campi
  • Eventi
  • Constructor (s)
  • Metodi
  • Proprietà
  • I delegati

Mi piace anche scrivere proprietà come questa (invece dell'approccio abbreviato) 

// 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; }
}
Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top