Prefisso di sottolineatura sulle variabili membro. intellisense

Question

tutti dicevano che il dibattito "underscore, no underscore" è puramente filosofico e guidato dalle preferenze dell'utente ma con intelli-sense che ha il carattere di sottolineatura consente di differenziare le variabili membro dalla variabile locale molto facilmente e quindi di fornire un vantaggio concreto

c'è qualche argomento contrario a questo vantaggio di avere trattini bassi per tutte le variabili membro?

Answer 1

Sì: per alcune persone riduce la leggibilità. Credo che le persone diverse leggano in modi diversi (alcuni vocalizzi interni e altri no, per esempio). Per alcune persone (me stesso incluso) i caratteri di sottolineatura interrompono il "flusso" del codice mentre lo sto leggendo.

Direi che se hai difficoltà a distinguere variabili locali e di istanza, probabilmente i tuoi metodi sono troppo grandi o la tua classe sta facendo troppo. Ovviamente non sarà sempre così, ma non tendo a trovarlo un problema con classi/metodi brevi.

Answer 2

L'utilizzo del trattino basso è solo un modo per ottenere questo effetto. L'importante è essere coerenti al riguardo.

Answer 3

Se è solo l'intellisense che vuoi puoi sempre capirlo digitando "this.".

OK, ci sono 4 caratteri in più di "_", ma l'intellisense mostrerà i tuoi membri per te.

Se si utilizzano caratteri di sottolineatura e il proprio team utilizza caratteri di sottolineatura, continuare a utilizzarli. Altri useranno "m _", altri potrebbero avere altre idee. Uso StyleCop e sul mio team il dibattito è finito, usiamo "this". e i prefissi di stile ungherese o di sottolineatura non sono usati. E non ci preoccupiamo più.

[Modifica] Questa non è una critica alla tua domanda - è una domanda valida e vale la pena di essere chiesta - ma questo dibattito fa perdere troppo tempo ai progetti di sviluppo. Anche se non mi piace affatto di StyleCop, lo utilizzo volentieri in quanto elimina questo tipo di dibattito. Seriamente, sono stato in riunioni da un'ora dove questo tipo di discussione occupa un intero team di sviluppo. Pazzo. Come ho detto, la tua domanda è valida ma per favore non sprecare il tuo tempo agonizzante su questo, non ne vale la pena :-)

Answer 4

Non importa quale convenzione di denominazione tu scelga fintanto che la usi in intero progetto.

Answer 5

Il carattere di sottolineatura può essere visto come una forma di notazione ungherese *, ma il prefisso è un "carattere magico" invece di qualcosa che ha un significato.

Se si desidera qualcosa che dice di più su a cosa serve il prefisso, si utilizzerà un prefisso come member o mbr o m. A volte viene utilizzato il prefisso m_, ma il trattino basso viene utilizzato come separatore anziché come parte del prefisso e le raccomandazioni di denominazione per .NET indicano che non deve essere utilizzato come separatore.

Personalmente sono arrivato ad apprezzare il carattere di sottolineatura per le variabili membro, anche se è un prefisso con un significato nascosto. Non ingombra i nomi tanto quanto qualsiasi altro prefisso.

E come sempre, è più importante scegliere uno standard e attenersi ad esso, rispetto a quale standard è che effettivamente scegli.

---

* notaition ungherese ha in gran parte finito per essere utilizzato per specificare il tipo di dati in lingue debolmente tipizzato come VBScript, ma l'intenzione originale era di specificare altre proprietà delle variabili, in modo da utilizzarlo per le variabili di utente è più lungo l'originale intenzioni.

Answer 6

Utilizzo di questo. Ovunque riduce la leggibilità secondo me. I prefissi di sottolineatura per i campi di classi private sono perfettamente accettabili. È un po 'ungherese che è una convenzione di denominazione davvero orribile e sul fronte intellettualistico _ più una lettera è un modo estremamente rapido per far apparire la tua lista. Io uso CSLA.NET e molti degli esempi BO usano la convenzione di sottolineatura e continuo a usarlo in tutto il mio lavoro. Non lasciare che gli ex sviluppatori di C++ e C della vecchia scuola ti spaventino a pensare che non sia una buona pratica - .NET non presenta gli stessi problemi. Un buon esempio è il passaggio di argomenti nei costruttori:

public MyObject(int field1, int field2, int field3) 
{ 
    _field1 = field1; 
    _field2 = field2; 
    _field3 = field3; 
} 

a mio parere è molto più leggibile rispetto

public MyObject(int field1, int field2, int field3) 
{ 
    this.field1 = field1; 
    this.field2 = field2; 
    this.field3 = field3; 
} 

Ma è gusto personale e come è stato detto altrove la coerenza è la questione più importante.