Convenzioni di denominazione variabile? [chiuso]

È possibile modificare ReSharper per utilizzare qualsiasi schema di convenzione di denominazione utilizzato. È abbastanza flessibile, compresa 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 imporre il tuo.

Aggiornamento: Detto questo, al lavoro usiamo principalmente casi di cammello inferiori 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 preoccupato in entrambi i modi.

Rispetto a

but is the underscore necessary? do you find it comfortable?

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

Considera:

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

senza il carattere di sottolineatura, dovresti scrivere:

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

che potenzialmente introduce l'errore sottile di:

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

Inoltre, il completamento del codice è più pulito perché legando semplicemente il trattino basso si ottiene un elenco solo dei campi privati, mentre con "questo" si ottiene un elenco di tutto.

Rispetto a

usually use Hungarian notation

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

DO NOT use Hungarian notation

Lascia poco spazio all'ambiguità:)

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

In C # che avvia il nome protetto o pubblico con underscore è contro Common Language Specification. È corretto solo in caso di membri privati.

Da MSDN:

To fully interact with other objects regardless of the language they were implemented in, objects must expose to callers only those features that are common to all the languages they must interoperate with. For this reason, the Common Language Specification (CLS), which is a set of basic language features needed by many applications, has been defined.

Vedi: link

Qui puoi leggere l'avviso sul trattino basso:

Element names starting with an underscore (_) are not part of the Common Language Specification (CLS), so CLS-compliant code cannot use a component that defines such names. However, an underscore in any other position in an element name is CLS-compliant.

Vedi: link

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. Sai a prima vista che la variabile è un membro della classe e privato.

Sicuramente l'IDE può dirti che quando passi il mouse sopra di esso, ma la "prima occhiata" non può essere battuta. Sai qual è una variabile locale, e che cosa è una variabile membro con i tuoi occhi da solo. Non sono richiesti scorrimento o mouse al passaggio.

È possibile utilizzare la parola chiave "this" ma _ è più breve per una migliore scansione orizzontale. I nomi descrittivi sono solitamente desiderati ma quando qualcosa è una convenzione stabilita è meglio avere 1 carattere. ad esempio, utilizzando la lettera i come indice durante il looping di un array. Poiché si tratta di una convenzione affermata secondo cui i è un indice, si ottiene il beneficio della scansione senza l'inconveniente di chiedersi cosa significhi "i".

Sono d'accordo generalmente con ciò che viene detto da altri, tuttavia quando si tratta di strumenti e catene di strumenti, sono pigro e come una vita facile. Trovo che la vita sia spesso più facile da fare semplicemente come loro suggeriscono. I motivi sono

• È più facile da installare (basta andare con i valori predefiniti, anche io posso premere Invio per 20 volte e andare avanti)
• Di solito i bug vengono elaborati con le impostazioni predefinite, spesso è la configurazione esoterica che ho impostato che espone un difetto per la prima volta
• Probabilmente il venditore della catena di strumenti ne sa più di me, quindi l'hanno fatto in quel modo per una ragione. Chi sono io per decidere che gli esperti sono sbagliati (li considero degli esperti, perché ho comprato il loro strumento)
• Non dovrai mai difendere la scelta dei fornitori da parte di un manager - "È quello che loro raccomandano"
• Il nuovo ragazzo non ti infastidirà con "perché" e "È meglio così" - Quando ogni risposta è "perché hanno deciso ..."

Quindi la mia opinione sarebbe se riesci a trovare un motivo valido per riconfigurare gli strumenti su cui hai appena speso una fortuna, a tutti i costi farlo. Se non puoi giustificare la modifica, non farlo.

Ricorda che ogni cambiamento ha un costo in corso (reale e nascosto) da mantenere. Meno ce ne sono, più basso è il costo. Per esempio - quel nuovo ragazzo che ho menzionato - nessun cambiamento significa che può leggere il loro manuale. Riconfigura - devi scrivere l'addendum, archiviarlo con altre cose, ritirarlo e convincerlo a leggerlo dopo aver letto il loro manuale. Forse non è un problema per un negozio di 2 uomini, ma che dire di un negozio di 100 uomini?

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

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

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

sDI

e farlo espandere a

someDescriptiveIdentifier

Salva un po 'di digitazione nel caso in cui hai nomi come

someDescriptiveName, someOtherDescriptiveName, someOtherButNotTheSameDescriptiveName

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

Usando caratteri di sottolineatura posso determinare quale nome voglio completare automaticamente

someDescriptiveIdentifier

o

_someDescriptiveClassMember

Spero che la mia spiegazione sia abbastanza chiara:)