Convenzioni di denominazione variabili? [chiuso]

Ho appena iniziato a usare ReSharper (per C #) e in un certo senso mi piace il suo finder di odori di codice, mi mostra alcune cose sulla mia scrittura che intendevo risolvere molto tempo fa (principalmente convenzioni di denominazione variabili).

Mi ha fatto riconsiderare alcune delle mie convenzioni di denominazione per metodi e variabili di istanza. ReSharper suggerisce che la variabile di istanza sia minuscola e inizia con un trattino basso. Per un po 'intendevo rendere tutte le mie variabili locali minuscole di cammello, ma il carattere di sottolineatura è necessario? Lo trovi comodo? Non mi piace questa convenzione ma non l'ho ancora provata, che ne pensi?

La seconda cosa che mi ha spinto a rivalutare sono le mie convenzioni di denominazione per i gestori di eventi della GUI. Di solito uso lo standard VS di ControlName_Action e i miei controlli di solito usano la notazione ungherese (come suffisso, per aiutare a chiarire nel codice cosa è visibile all'utente e cosa non lo è quando si tratta di variabili con nomi simili) quindi finisco con OK_btn_Click ( ), qual è la tua opinione al riguardo? Devo soccombere alla convenzione ReSharper o ci sono altre opzioni ugualmente valide?

È possibile modificare ReSharper per utilizzare qualsiasi schema di convenzione di denominazione utilizzato. È abbastanza flessibile, inclusa la personalizzazione di gestori di eventi, campi, proprietà, metodi con vari livelli di accessibilità ecc.

Non lasciare che lo strumento definisca i tuoi standard: usalo per far valere i tuoi.

Aggiornamento: Detto questo, al lavoro utilizziamo principalmente un caso di cammello inferiore per la maggior parte delle cose private: variabili, campi e argomenti. Caso di cammello superiore per nomi di metodi, costanti e proprietà. I gestori di eventi sono denominati in base all'azione che rappresentano, piuttosto che a qualcosa di specifico per il controllo, ad esempio HandleCustomerContinue anziché HandleContinueButtonClick. Ho provato lo schema predefinito di ReSharper per un po 'e in realtà non mi dispiace, non sono davvero agitato in entrambi i modi.

Riguardo a

ma è necessario il carattere di sottolineatura? lo trovi comodo?

Una cosa che mi piace molto dell'uso del trattino basso è che riduce drasticamente l'uso di "questo".

Prendere in considerazione:

public void Invoke(int size) {
    _size = size;
}

senza il trattino basso, dovresti scrivere:

public void Invoke(int size) {
    this.size = size;
}

che potenzialmente introduce il sottile errore di:

public void Invoke(int size) {
    size = size;    // urgh ... no this! 
}

Inoltre, il completamento del codice è più pulito perché semplicemente legando la sottolineatura si ottiene un elenco di soli campi privati, mentre con "questo" si ottiene un elenco di tutto.

Riguardo a

di solito usano la notazione ungherese

le Linee guida per la progettazione di framework: convenzioni, Idom e pattern per librerie .NET riutilizzabili dicono:

NON utilizzare la notazione ungherese

Lasciando poco spazio all'ambiguità:)

La coerenza è davvero la chiave. Questo e la chiarezza, cioè non essere criptici o cercare di salvare la digitazione abbreviando tutto. Intellisense è il tuo risparmiatore di battitura, non nomi criptici (ma brevi!).

In C # l'avvio di un nome protetto o pubblico con trattino basso è contrario a Common Language Specification. È corretto solo in caso di membri privati.

Da MSDN:

Per interagire pienamente con altri oggetti indipendentemente dalla lingua in cui sono stati implementati, gli oggetti devono esporre ai chiamanti solo le funzionalità comuni a tutte le lingue con cui devono interagire. Per questo motivo, è stata definita la Common Language Specification (CLS), che è un insieme di funzioni linguistiche di base necessarie a molte applicazioni.

Vedi: http://msdn.microsoft.com/en-us/library/12a7a7h3.aspx

Qui puoi leggere gli avvertimenti sul carattere di sottolineatura:

I nomi degli elementi che iniziano con un trattino basso (_) non fanno parte della Common Language Specification (CLS), quindi il codice conforme a CLS non può usare un componente che definisce tali nomi. Tuttavia, un carattere di sottolineatura in qualsiasi altra posizione nel nome di un elemento è conforme a CLS.

Vedi: http://msdn.microsoft.com/en-us/library/81ed9a62.aspx

I membri protetti sono un problema perché puoi ereditare dalla classe scritta in un'altra lingua.

Ma forse non è un problema nel tuo caso se non hai bisogno del codice compilatore CLS.

Mi piacciono i caratteri di sottolineatura. A prima vista, sai che la variabile è un membro della classe e privato.

Sicuramente l'IDE può dirti che quando ci passi sopra con il mouse, ma il "primo sguardo" non può essere battuto. Sai cos'è una variabile locale e qual è una variabile membro solo con i tuoi occhi. Non è richiesto lo scorrimento o il passaggio del mouse.

È possibile utilizzare la parola chiave "this" ma _ è più breve per una migliore scansione orizzontale. I nomi descrittivi sono generalmente desiderati, ma quando qualcosa è una convenzione stabilita è meglio avere 1 carattere. ad esempio, usando la lettera i come indice durante il looping di un array. Dal momento che è una convenzione stabilita che io sia un indice, ottieni il vantaggio della digitalizzazione senza l'inconveniente di chiederti cosa significhi "i".

Concordo in generale con ciò che viene detto dagli altri, tuttavia quando si tratta di strumenti e catene di strumenti, sono pigro e mi piace una vita facile. Trovo che la vita sia spesso più semplice semplicemente come loro suggeriscono. Le ragioni sono

• È più facile da installare (basta andare con le impostazioni predefinite, anche io posso premere Invio 20 volte e farlo funzionare)
• I bug di solito sono stati elaborati fuori dalle impostazioni predefinite, spesso è la configurazione esoterica che ho impostato che espone un difetto per la prima volta
• Il venditore della catena di utensili probabilmente ne sa più di me, quindi lo hanno fatto in quel modo per un motivo. Chi sono io per decidere che gli esperti hanno torto (li considero esperti, perché ho comprato il loro strumento)
• Non dovrai mai difendere la scelta dei venditori da parte di un Manager - "È quello che raccomandano"
• Il nuovo ragazzo non ti disturberà con "perché" e "È meglio così" - Quando ogni risposta è "perché hanno deciso ..."

Quindi la mia opinione sarebbe se riuscissi a trovare un motivo valido per riconfigurare gli strumenti su cui hai appena speso una fortuna, e in ogni caso fallo. Se non riesci a giustificare la modifica, non farlo.

Tieni presente che ogni modifica ha un costo in corso (reale e nascosto) da mantenere. Meno ci sono, minore è il costo. Ad esempio, quel nuovo ragazzo di cui ho parlato, nessuna modifica significa che può leggere il loro manuale. Riconfigura: devi scrivere l'addendum, archiviarlo con altre cose, ritirarlo e farlo leggere dopo aver letto il loro manuale. Forse non è un problema per un negozio di 2 uomini, ma per quanto riguarda un negozio di 100 uomini?

Le due regole che stai chiedendo, sottolineano all'inizio dei nomi dei campi privati ​​e i nomi dei metodi sono generalmente considerati la norma nei circoli di sviluppo di C #. Adattandosi a tali convenzioni, il codice sarà immediatamente più comprensibile per gli altri sviluppatori perché è questo lo stato d'animo a cui sono abituati a operare.

Il suffisso di Label, RadioButton, ecc. Per i tuoi controlli è generalmente considerato anche la norma. Spesso esistono più controlli per un singolo concetto (ad esempio un'etichetta e una casella di testo) e questo suffisso è abbastanza utile. La vera notazione ungherese è stata abbandonata molto tempo fa perché è stata trasformata in qualcosa che non esprime il suo intento originale, che era il contesto della variabile e non il tipo, la dimensione, ecc.

Nel mio caso, l'uso di camelcase e underscore aiuta con i nomi delle variabili descrittivi (leggi: lunghi) e il completamento del codice. Non sono sicuro di come funzioni il completamento automatico di Visual Studio, ma in QtCreator e, in misura minore, in Eclipse, si può digitare, ad esempio

sDI

e lo hanno ampliato a

someDescriptiveIdentifier

Salva un po 'di digitazione nel caso abbiate nomi come

someDescriptiveName, someOtherDescriptiveName, someOtherButNotTheSameDescriptiveName

che tendo a produrre in "modalità di denominazione descrittiva".

Usando i trattini bassi posso determinare quale nome voglio compilare automaticamente

someDescriptiveIdentifier

o

_someDescriptiveClassMember

Spero che la mia spiegazione sia abbastanza chiara :)