Mi chiedevo se esistesse uno standard per la stesura delle regioni di una classe.
Attualmente utilizzo
Fields
Constructor
Properties
Public Methods
Private Methods
Fields è proprietà privata e Properties è quelle pubbliche. Normalmente userò le subregioni all'interno di questo se necessario, o aggiungerò occasionalmente altre regioni di seguito (come i membri dell'interfaccia o di baseClass).
Enums legati alla classe o occasionalmente struct / pure-data classes (sopra la definizione effettiva della classe)
--- Definizione della classe ---
Membri privati
CTOR / DTOR se la lingua ha DTOR
Proprietà pubbliche
Metodi di utilità (metodi privati o protetti con scope di piccole dimensioni)
Funzionalità di classe (può essere divisa in più regioni a seconda dell'ambito della classe).
Sottoregioni? La tua classe ha una Single Responsibility ? (implicito in questo ... la mia risposta è "Raramente qualsiasi regione, eccetto forse per raggruppare proprietà, costruttori e metodi" ... ma anche così, non la uso così tanto)
Volevo solo confermare che intendevi "#regions" e non il layout di classe in generale.
Sono sorpreso che nessuno abbia menzionato per evitare l'uso delle regioni. Capisco che il PO voglia partecipare a un sondaggio sulla sistemazione delle regioni, ma mi piacerebbe creare un punto di vista alternativo.
Evito le regioni. Mi piace vedere il codice con cui lavoro. Se trovi difficoltà a trovare ciò che stai cercando, usa la combinazione di codice e raggruppa insieme costrutti di classi simili.
Perché odio le regioni? CTRL + M, L e CTRL + M, O attiva / disattiva la piegatura del codice. Tuttavia, quando crolla nasconde l'intera regione. Ho solo bisogno di comprimere metodi / proprietà / commenti.
Se ci sono troppe regioni, forse è un odore di codice e la tua classe sta facendo troppo lavoro. Jeff Atwood fornisce un buon post su regioni che vale la pena leggere.
La mia citazione preferita su #regions:
No, I will not use #regions. And no, I DO NOT NEGOTIATE WITH TERRORISTS. Shut up.
Detto questo, so che molti programmatori insistono nel loro utilizzo. Questa domanda è soggettiva. Avevo appena pensato di offrire un'alternativa.
Varia da una lingua all'altra. Dato che sono un programmatore Delphi, tendo a seguire la convenzione standard di Delphi, che assomiglia a questo:
type
TMyClass = class(TBaseClass)
private
private fields
private methods
protected
protected fields
protected methods
protected properties
public
constructor(s)
destructor
public methods
public properties
end;
Trovo un buon modo per organizzare informazioni facili da leggere e comprendere.
Tendo a indicarli nel seguente modo:
Public fields (usually static constants)
Constructors
Public methods
Private methods
Private fields
Non ho usato un linguaggio che usa Properties , ecco perché non sono disposti. Metto i metodi e i campi privati in fondo perché se qualcun altro sta usando questo file nel loro codice, dovrebbero solo occuparsi dell'API, che è la roba pubblica. E tutti gli editor di testo che conosco, e persino gli IDE, posizionano il cursore in alto quando aprono i file.
È un giudizio per me. Uso le regioni quando sono necessarie per la leggibilità.
Uso anche un colore diverso nella mia combinazione di colori di Visual Studio (attualmente un rosso scuro) per farli risaltare dal resto del codice.
Un esempio di dove potrei usare una #region: se scrivo un metodo di test per un test unitario che richiede uno snippet multilinea di XML, la stringa XML interromperà il solito rientro (poiché inizia lungo la sinistra) margine della mano della finestra del codice. Per nascondere la bruttezza, lo avvolgerò in una #region, in modo che possa crollare.
Il libro Pulisci codice di Bob Martin dedica l'intero quinto capitolo alla formattazione. Ci sono un paio di punti chiave che ritengo piacevolmente riassumono.
Mantenere il codice combinato con elementi di interazione comune in verticale ravvicinati rimuove efficacemente qualsiasi necessità di creare regioni specifiche. Se il tuo codice è così lungo da richiedere che le regioni nascondano un sacco di codice, forse questo è un odore di codice che indica che la classe sta cercando di fare troppo. Forse alcune delle funzionalità possono essere spostate in una classe di utilità o inviate a un antenato.
Se hai bisogno di "nascondere" il codice perché è troppo lungo o troppo "brutto", probabilmente avrai problemi più grandi di cui preoccuparti se non usare o meno le regioni. Personalmente non ho mai bisogno di usarli, e quando lavoro sul codice di qualcun altro, trovo che devo sempre aprirli tutti comunque, quindi perché preoccuparsi?
Attualmente sto organizzando classi come questa:
class types
constructors
destructor
accessors
methods
properties (where properties are present in the language)
member variables
e quindi prefisso il livello di accesso a ciascuna dichiarazione (sorta di, a volte gruppo per accesso). Ero solito fare il raggruppamento di primo livello per accesso, ma a un certo punto, non so quando, non ha funzionato abbastanza bene come sopra. Ad esempio in C ++ / CLI (che sono costretto a usare al momento :-() puoi farlo, che rovina il raggruppamento per accesso:
public: property int SomeProperty
{
private: void set (int value) { ... }
public: int get () { ... }
}
Risposta marginale di Lunatic: No, almeno quando si tratta di C #. Tra Visual Studio e R # posso navigare magicamente verso qualsiasi membro o implementazione, quindi non c'è alcun punto nell'ossessione di questa roba; inizia a digitare dove si trova il cursore.
Come Wyatt e un paio di altre risposte, in genere evito anche l'uso delle regioni. Le regioni hanno uno scopo; per nascondere il codice che non vuoi vedere. Se hai un sacco di codice in una classe che non vuoi vedere, e quindi hai bisogno di molte regioni per permetterti di comprimere detto codice, probabilmente nella classe ci sono troppi codici. ReSharper non rispetta le regioni quando decide dove posizionare il nuovo codice, a meno che non abbia creato la regione (cosa che fa per le implementazioni dell'interfaccia).
L'unico uso delle regioni che trovo accettabile è quello di nascondere il codice "inevitabilmente brutto"; codice che tratta dettagli specifici di implementazione che non possono essere ben architettati internamente agli standard attuali. Questo è in genere un codice esoterico avanzato, che in genere non dovrebbe essere incasinato dal programmatore junior medio una volta scritto. Sono cose come:
Leggi altre domande sui tag programming-practices .net