Convenzione di denominazione delle variabili nel linguaggio di programmazione C # [chiuso]

Sto guardando un video su C # sulle variabili. L'autore dichiara una variabile all'interno di un metodo e l'ha nominata in questo modo: string MyName = "James";

la mia domanda è: quale convenzione è raccomandata da .Net Framework. È un involucro Pascal come nell'esempio sopra o è un caso di cammello?

c# coding-standards variables conventions

— Kaser
fonte

Il problema con questa domanda, che non sapevi, quindi non è colpa tua, è che in realtà non esiste una convenzione canonica per C #. Ci sono convenzioni comuni; sfortunatamente più di uno, ma sarebbe abbastanza difficile per te ottenere una risposta che non sia pura opinione. Spiacente, votando per chiudere; il mio consiglio: dedica un po 'di tempo a leggere il codice nei repository github e codeplex popolari per vedere quali convenzioni usano come persone che scrivono la maggior parte di quelle popolari sono persone con esperienza nel settore e canoniche per ciò che è comune come troverai.

— Jimmy Hoffa,

Convenzioni di denominazione da MSDN - msdn.microsoft.com/en-us/library/xzf533w0(v=vs.71).aspx

— Yusubov

@Yusubov Descrivono la denominazione delle parti pubbliche delle librerie, non delle variabili locali.

— svick,

Risposte:

Non penso che ci sia qualcosa di simile a una convenzione "ufficiale". Per quanto ne so, quanto segue è considerato una buona pratica da molti sviluppatori C # esperti:

PascalCase for public member variables (string MyName = "James")

camelCase for local variables (string myName = "James")

_leadingUnderscore for private member variables (string _myName = "James")

Con questo approccio, si può distinguere tra variabili locali e membri pubblici e privati dal caso della loro prima lettera.

Come in ogni convenzione di codifica, anche questo è soggetto alle preferenze personali. Pertanto, non esiste una risposta definitiva. Un obiettivo generale dovrebbe essere quello di mantenere il codice il più leggibile e comprensibile possibile.

— glaed
fonte

+1 Questo è vicino allo stile che ho visto. Credo che sia generalmente preso dallo stile usato negli esempi di MSDN. Di solito vedo ottenere proprietà PascalCase, ottenere locali camelCasee ottenere membri privati _leadingUnderscore.

— KChaloux,

Intendi Campi o Proprietà quando hai detto variabili membro?

— Kaser,

Sviluppatori Delphi tendono a parametri funzione nome / metodo anteponendo un 'un': (aParameter: string). Mi rendo conto che i parametri sono essenzialmente variabili locali, specialmente se passati per valore, ma spesso è molto utile "vedere" che un var è effettivamente passato come parametro. Esiste una simile convenzione in C #?

— Marjan Venema,

E un altro: campi membri. I delfiani li precedono con una 'F'. Ho visto il codice C # che li dichiara con una sottolineatura: private string _SomeString. Diresti che è una convenzione? (Sto solo immergendo le dita dei piedi in C # e chiedendomi queste cose).

— Marjan Venema,

Questo è inaccurato. Esistono convenzioni di denominazione pubblicate per membri pubblici (e classi pubbliche ecc.).

— svick,

Le Convenzioni di denominazione del .Net Framework ( v4.5 , v1.1 ) non sono d'accordo su questo. Non specificano uno standard per la denominazione delle variabili locali. Dovrai decidere la tua convenzione per nominarli.

Personalmente uso camelCase e disambiguo le variabili membro dai nomi dei parametri thisquando necessario. Ma _memberVariablesono validi anche i trattini bassi (cioè ).

— Robert Harvey
fonte

Questo è esattamente il motivo dell'utilizzo delle convenzioni di denominazione, che consente thisdi distinguere le variabili locali dai campi / proprietà. 5 lettere aggiuntive ogni volta è troppo imho.

— Sinatr,