Qual è la migliore pratica, convenzioni di denominazione più comunemente accettate per le variabili private in C #?
private int myInteger; private int MyInteger; private int mMyInteger; private int _myInteger; private int _MyInteger; Che usi e perché? (La mia azienda è abbastanza nuova per C # e vorrei scegliere il metodo più "accettato dal settore" per cercare di entrare nel nostro standard di codifica.)
Uso l'opzione n. 4 sopra:
private int _myInteger;
Mi piace avere qualche indicazione di ambito nei miei nomi di variabili, e il trattino basso è sufficiente a tale scopo. È anche abbastanza facile da leggere.
Uso il seguente schema di denominazione:
Penso che l'opzione 4 sia davvero l'opzione più leggibile. Ti aiuta a farlo:
public Person(string name, int age)
{
this.name = name;
this.age = age;
}
Rende anche più visibili tutti i membri privati. Nell'esempio seguente, dove diamine è age proveniente da? Senza il qualificatore this è più difficile da dire.
private void Method()
{
var x = 2;
var y = age + x;
}
Questo è molto più facile da capire:
private void Method()
{
var x = 2;
var y = _age + x;
}
Prima di tutto, PascalCasing è comunemente riservato per proprietà pubbliche, metodi, metodi, ecc. della classe. Quindi salterò il 2 e il 5.
In secondo luogo, la notazione ungherese è scoraggiata nel mondo .NET, quindi (uh, penso) 3 è giusto. Supponendo che ciò che sta succedendo con 3.
Questo lascia CamelCasing e _camelCasing. Di solito uso _camelCasing per le variabili di classe e semplice vecchio camelCasing per le variabili con scope a un metodo o più ristretto. L'involucro Camel è lo standard accettato per gli argomenti del metodo, i nomi delle variabili protette / private e le variabili all'interno di un metodo o di uno scope più ristretto.
Mi piace anche anteporre il carattere di sottolineatura in modo che le mie variabili private siano raggruppate nel mio intellisense. Tuttavia, lo faccio solo per le variabili con scope per un tipo. Variabili dichiarate all'interno di un metodo o ambito più stretto Lascio la sottolineatura fuori. Rende facile tenerli separati e tenere insieme le variabili meno utilizzate.
private int integer
Se vieni confuso tra membro e variabili locali in un ambito del metodo, probabilmente devi refactoring.
Credo che il modo migliore per farlo (in C # /. net comunque) è una combinazione di 2 e 6:
private int MyInteger { get; set; }
In teoria non esiste alcuna variabile, ma sembra e si comporta come una variabile di istanza privata. Se abbiamo bisogno di aggiungere qualche logica di business a quel valore (è un valore completamente interno, quindi possiamo fare tutto ciò che vogliamo dopo tutto), allora è già 'proprietà' per noi. Una tazza di vittoria fumante!
Faccio l'opzione # 4 perché è quello che sembra l'SSCLI, ma sinceramente non mi interessa molto sulla denominazione della variabile privata. Il pubblico è una storia diversa.
BTW hai dimenticato m_MyInteger
Non lo chiamerei "mio" niente!
Ma direi
class C
{
int VariableName { get; set; }
}
molto spesso questo è più bello di avere variabili esplicite. Se avessi una variabile privata esplicita, la chiamerei int _variableName;
In C ++ tendo ad usare _ perché cambio molto gli editor, il che non mi permette di vedere se è privato.
Per C # Tendo a lasciare il _ away come Visual Studio mi permette di vedere se è privato.
Tendo ad usare il Camel Case per farlo.
Io uso 4 ( private int _myInteger; ) perché:
private int myInteger;
Ecco come nomino le mie variabili locali.
private int MyInteger;
Ecco come nomino le costanti.
private int mMyInteger;
Questo non è in stile C #.
private int _MyInteger;
Questo sembra strano.
con il carattere di sottolineatura.
Bill Wagner spiega perché in C # efficace . Ma non chiamerei mai un intero il mio numero intero , meglio qualcosa come _age o _length. Includere TypeName nel nome dell'istanza è una pratica orribile. I nomi dovrebbero essere auto esplicativi e dato che C # è di tipo Type-Safe può essere trovato in qualsiasi momento.
Devi dare un esempio più specifico, ma:
private int count , private int badFileCount , private static readonly int ReconnectAttemptsLimit
A proposito, ottieni tutto questo GRATIS quando installi e inizi a utilizzare il più recente e massimo MSFT Stylecop .
Vado con l'opzione 5: private int _MyFoo
Non vedo alcun vero vantaggio competitivo su _myFoo però.
Utilizza camelCasing per variabili private come myInteger
Considera un _ precedente se la variabile è un backup per una proprietà per ridurre le confusioni-
Variabile _myProperty per proprietà MyProperty
Ho il nome ReSharper delle mie variabili, non solo il mio ma anche tutti gli altri lo fanno. C'è una grande quantità di coerenza attraverso il progetto.
Lo standard di codifica C # IDesign di Juval Lowy è molto popolare. Questo standard consiglia di anteporre le variabili dei membri privati con "m_" (opzione 6). Questo è ciò che facciamo nel nostro team.
private int m_myInteger;
L'opzione 4 ( _myInteger ) è una variazione accettabile di questo standard.
Non mi piaceva il consiglio MSDN ( myInteger ), perché rende difficile distinguere un membro privato da una variabile locale. La loro raccomandazione, ovviamente, risolve questo problema qualificando i membri privati con this , che mi sembra ridondante.
Leggi altre domande sui tag variables coding-standards naming