Perché non dovrei prefisso miei campi?[chiuso]

Question

Io non sono mai stato un fan di notazione ungherese, ho sempre trovato abbastanza inutile a meno che non si stia facendo qualcosa di veramente programmazione a basso livello, ma in ogni progetto di C++ ho lavorato su un qualche tipo di notazione ungherese politica è stata applicata, e con essa anche l'uso di un po 'di non-davvero-ungherese prefissi m_ per i campi, s_ per la statica, la g_ per globals e così via.

Presto mi resi conto di quanto inutile è stato in C# e gradualmente ha iniziato a cadere tutte le mie vecchie abitudini...ma il 'm_' cosa.Io uso ancora il m_ prefisso campi privati perché trovo davvero molto utile per essere in grado di distinguere tra i parametri, i locali e i campi.

Il convenzioni di denominazione per i campi pagina di MSDN dice che non dovrei, ma non è detto perché (il modo in cui ad es.Google convenzioni in genere tendono a razionalizzare le loro prescrizioni).

Ci sono motivi per cui non dovrei, o è solo una questione di stile.Se è quest'ultimo, sono prefissi generalmente considerato un cattivo stile e posso prevedere le reazioni negative di altre persone che lavorano sul codice?

Answer 1

Mi piace il carattere di sottolineatura prefisso per campi di membro.Soprattutto mi piace perché in questo modo, tutti i miei campi di membro sono mostrati, in ordine alfabetico, prima che i miei metodi nella procedura guidata barra nella parte superiore dello schermo.

Answer 2

Quando si deve:

• Quando il progetto linee guida di codifica dire che si dovrebbe

Quando non si deve:

• Quando il progetto linee guida di codifica dire che non si deve

Se non si dispone di eventuali linee guida di sicurezza, sei libero di scegliere qualunque cosa voi o il vostro team e si sentono più confortevole con.Personalmente quando si codifica in C++ io tendo ad usare m_ per i soci, non aiutano.Quando si codifica in altre lingue, in particolare di coloro che, senza una vera classi (come il Javascript, Lua) non ce l'ho.

Insomma io non credo che ci sia un "giusto" e "sbagliato".

Answer 3

L'auto di proprietà implementata funzione in C# 3.0 crea meno bisogno di questo congresso un modo o l'altro.Invece di scrivere

string m_name;
public string Name { get { return m_name; } }

o

string _Name;
public string Name { get { return _Name; } }

(o di qualsiasi altra convenzione), è ora possibile scrivere

public string Name { get; private set; }

Poiché non è più necessario l'esplicito archivio di backup variabile, non è più necessario venire con un nome per esso;evitando di tutta questa discussione.

Ovviamente, questo discorso non si applica quando si ha realmente bisogno esplicito archivio di backup come eseguire la convalida.

Answer 4

Come qualcuno ha già accennato, il MS guida dice:

Non utilizzare un prefisso per i nomi di campo.Per esempio, non utilizzare g_ o s_ per distinguere statici e non statici campi.

Mi capita d'accordo con questo.i prefissi di fare la vostra ricerca codice di brutto e spreco di spazio priva di caratteri.Detto questo, spesso è comune l'uso di campi per eseguire le proprietà in cui il campo e la struttura potrebbe avere lo stesso nome (con il privato, campo da camel case e proprietà in pascal).In VB, questo non funziona, dato che VB non è case-sensitive.In questo scenario, vi consiglio l'utilizzo di un unico prefisso_.Niente di più, niente di meno.Sembra proprio cleaner, IMHO.

Answer 5

Ho sperimentato con m_, s_, solo _, e nessun prefisso a tutti.Ho deciso di usare solo _ per tutti statici e variabili di istanza.Io non la trovo importante distinguere le variabili statiche da variabili di istanza.In teoria suona bene, in pratica non crea un problema.

Un collega una volta ha fatto un argomento convincente per eliminare tutti i prefissi, abbiamo provato su un progetto e ha funzionato meglio di quanto pensassi.Ho portato avanti per il mio prossimo progetto ed è infastidito che "interferisce" con Intellisense.Quando si ha la seguente situazione

int foo;
public int Foo
{
  get { return foo; }
}

Iniziando a digitare pippo suggeriscono sia la variabile di istanza e la proprietà.Anteponendo la variabile con un carattere di sottolineatura permette di eliminare il fastidioso doppio suggerimento, così ho cambiato di nuovo solo _.

Answer 6

Cerco di seguire il MSDN .Libreria di rete di linee guida.Essi comprendono un le linee guida di denominazione sezione.

Ovviamente, questi sono secondari per le linee guida del progetto.

Answer 7

Io preferisco marchio di proprietà di campi di backup (anche se, come già accennato .NET 3.0+ riduce il bisogno di grazie alle Proprietà Automatico con caratteri di sottolineatura, ma non la "m".Per uno che li mette in cima alla InteliSense elenco, quando vengo a usarli.

Devo ammettere che ho bisogno di ripassare le linee guida su MSDN, le cose possono cambiare molto rapidamente in questi giorni.

Answer 8

Con strumenti come resharper non c'è davvero alcun motivo per prefissi.Anche se la scrittura di brevi metodi, si dovrebbe essere in grado di dire molto in fretta, dove il var è venuta da.Infine, credo di non vedere davvero il bisogno di raccontare una differenza tra statico o no, perché di nuovo resharper sta per red line se si tenta di fare qualcosa che non sei in grado di.Anche senza resharper, probabilmente hai salvato dal compilatore.

Answer 9

Mi sono sempre prefisso di variabili membro con m_ e le variabili statiche con s_ per le stesse ragioni per cui è stato.Alcune persone prefisso variabili membro con un carattere di sottolineatura, ma questo l'ho sempre trovato un po ' strano (ma questa è solo una preferenza personale).

La maggior parte delle persone con cui lavoro utilizza il m_/s_ prefisso.Io non credo che le questioni troppo quello che si utilizza, se sei coerente.

Answer 10

Non li utilizzo mai.Incoraggia sciatta di codifica.MSDN linee guida di codifica, che è dove sta.

Answer 11

Qui ci sono alcuni motivi per uso _ (e non m_).

(1) Molti BCL ragazzi farlo nonostante MS la denominazione di guida.(Check out loro blog.) Quei ragazzi di scrivere il quadro, in modo che essi hanno alcune buone abitudini che vale la pena di copia.Alcuni dei più utili codice di esempio su MSDN è scritto da loro, e quindi utilizza il carattere di sottolineatura convenzione.Si tratta di un de-facto standard del settore.

(2) Una sola sottolineatura è un evidente e discreto modo per disambiguare metodo e variabili a livello di classe, semplicemente leggendo il codice.Esso aiuta le persone a capire i nuovi (o vecchi) codice a colpo d'occhio durante la lettura.Sì, è possibile il mouse, per vedere questo in un IDE, ma non dovremmo essere costretti.Puoi leggere in un editor di testo, o oserei dire, sulla carta.

(3) Alcuni dicono che non è necessario alcun prefisso metodi sarà breve, e in seguito, se necessario, è possibile modificare il campo per un'auto di proprietà implementata.Ma nel mondo reale, i metodi di come devono essere, e ci sono importanti differenze tra i campi e le proprietà (ad es.la serializzazione e l'inizializzazione).

Nota a piè di pagina:La "m" per gli stati in m_ è ridondante nel nostro uso qui, ma è stata inferiore nel caso, perché una delle idee che in molte di queste vecchie convenzioni di denominazione è che tipo di nomi iniziato con maiuscole e i nomi di istanza iniziato con minuscole.Che non si applica nel .NET è doppiamente ridondante.Anche la notazione ungherese è stato utile a volte con i vecchi compilatori C (ad es.intero o puntatore casting e aritmetica), ma anche in C++ la sua utilità è stata diminuita quando ha a che fare con le classi.

Answer 12

C'è una differenza importante tra C++ e C#:Strumento di supporto.Quando si seguono le linee guida stabilite (o varianti comuni), si ottiene un livello più profondo di strumento di supporto che il C++ non ha mai avuto.Seguendo gli standard consente l'uso di strumenti per fare di più profondo di refactoring/operazioni di ridenominazione di quanto si potrebbe altrimenti essere in grado di.Resharper fa questo.Così bastone con uno degli standard stabiliti.

Answer 13

Come @Giovanni Kraft cita, non c'è risposta "corretta".MattJ è il più vicino, si dovrebbe sempre attenersi alle linee guida dell'azienda.Quando, a Roma, e che.

Per quanto riguarda il mio parere personale, dal momento che è qui, io voto che si trascina m_ interamente.

Credo che lo stile migliore è quello in cui tutti i membri sono PascalCased, a prescindere dalla visibilità (che significa anche private membri), e tutti gli argomenti sono camelCased.Io non la rottura di questo stile.

Posso capire il desiderio di prefisso proprietà archivio di backup campo;dopo tutto, è necessario distinguere tra il campo e la proprietà, giusto?Sono d'accordo, è necessario.Ma usare un post-fix.

Invece di m_MyProperty (o anche _MyProperty, che ho visto e anche promosso un tempo), uso MyPropertyValue.E ' più facile da leggere e capire, e-cosa più importante-è vicino al tuo nome di proprietà originale in intellisense.

In definitiva, questo è il motivo preferisco un postfix.Se voglio accedere MyPropertyValue utilizzo di intellisense è (in genere) di tipo "My <down-arrow> <tab>"dal sei abbastanza vicino che solo MyProperty e MyPropertyValue sono sulla lista.Se si desidera accedere m_MyProperty utilizzo di intellisense, dovrete digitare "m_My <tab>".

Si tratta di battitura economia, a mio parere.

Answer 14

Io non faccio mai questo e il motivo è che I [prova] a mantenere i miei metodi brevi.Se posso vedere l'intero metodo sullo schermo, riesco a vedere i parametri, posso vedere la gente del posto e posso dire che è di proprietà di una classe e che cosa è un parametro o di un locale.

Faccio in genere il nome di mio params e locali utilizzando una particolare notazione, ma non sempre.Io non sono nulla se non in contrasto.Faccio affidamento sul fatto che i miei metodi sono brevi e cercare di impedire loro di fare X, Y e Z, quando dovrebbero essere solo facendo X.

Comunque, ecco i miei due centesimi.

Answer 15

A meno che mi sono bloccato con vi o Emacs per la modifica del codice, il mio IDE si prende cura di visualizzazione differenziale di membri per me, così ho raramente utilizza particolari convenzioni.Che vale anche per l'inserimento di interfacce di I o classi con C.

Qualcuno, per favore, spiegare il .NET style di I-prefisso interfacce.:)

Answer 16

quello che mi sono abituato, è che la proprietà privata è diventato piccolo underscone f.ex "stringa _name".il pubblico ha un "Nome".e le variabili di input in metodi ottenuto piccola lettera"void MyMethod(string name)".

se hai static const è spesso scritto con lettere grandi. static const MYCONST = "hmpf".

Answer 17

Non ho mai utilizzare qualsiasi ungherese verruche ogni volta che mi sono data la scelta.Extra di digitazione e di non trasmettere alcuna informazione utile.Qualsiasi buon IDE (e posso definire "buona", basato sulla presenza di questa funzionalità, tra gli altri) vi permetterà di avere diversi evidenziazione della sintassi per i membri statici, membri di istanza, membro funzioni, tipi, etc.Non c'è motivo di ingombrare il vostro codice con le informazioni che possono essere forniti dall'IDE.Questo è un corollario di non ingombrare il vostro codice commentato codice vecchio perché il vostro sistema di versioning dovrebbe essere responsabile per quella roba.

Answer 18

Il modo migliore è quello di stabilire uno standard con i tuoi colleghi, e bastone ad esso.Non è assolutamente necessario essere il metodo che avrebbe funzionato meglio per tutti, basta accordarsi su un metodo è più importante che il metodo è in realtà d'accordo.

Quello che abbiamo scelto per il nostro codice standard è quello di utilizzare _ come prefisso per le variabili membro.Uno dei motivi era che rende facile per trovare le variabili locali di intellisense.

Prima abbiamo concordato che standard ho usato un altro.Non ho usato alcun prefisso, e scrisse this.memberVariable il codice per mostrare che stavo usando una variabile membro.

Con la proprietà abbreviata in C# 3, trovo che io uso molto meno esplicito, le variabili membro.

Answer 19

La cosa più vicina alle linee guida ufficiali è StyleCop, uno strumento da Microsoft in grado di analizzare i file di origine e di rilevare violazioni raccomandati stile di codifica, e può essere eseguito dall'interno di Visual Studio e/o automatizzati, costruisce come MSBuild.

Usiamo sui nostri progetti e non aiutano a rendere il codice stile e il layout più coerente tra sviluppatori, anche se essere avvertiti di non prendere abbastanza un po ' di tempo per abituarsi!

Per rispondere alla tua domanda - non consentire alcuna notazione ungherese, né prefissi come m_ (infatti, non permette l'uso di caratteri di sottolineatura a tutti).

Answer 20

Io non uso stile più.È stato sviluppato per aiutarvi a vedere rapidamente come variabili sono stati utilizzati.Il più recente dev ambienti permetterà di vedere che informazioni posizionando il mouse sopra la variabile.L'esigenza è andato via, se l'utilizzo di tali strumenti più recenti.

Answer 21

Ci possono essere anche alcune informazioni che emergono dal C++ Standard Di Codifica (Sutter, Erba e Alexandrescum Andrei, 2004).Item #0 è intitolato "non sudare le piccole cose.(O:Sapere cosa non standardizzare i.)".

Toccano questa specifica domanda un po ' dicendo "Se non è possibile decidere la propria convenzione di denominazione, provare ...variabili membro private likeThis_ ..." (Ricordate l'uso della sottolineatura è soggetto a regole ben precise in C++).

Tuttavia, prima di arrivare lì, mettono in risalto un certo livello di coerenza "...la cosa importante non è stabilire una regola, ma solo per essere coerente con lo stile già in uso all'interno del file..."

Answer 22

Il beneficio di tale notazione in C/C++ è stato quello di rendere più facile vedere ciò che il tipo di un simbolo è stato, senza dover andare a cercare la dichiarazione.Questi stili è apparso prima dell'arrivo di Intellisense e "Vai a Definizione" - abbiamo spesso dovuto andare su un inseguimento d'oca alla ricerca per la dichiarazione in chissà quanti file di intestazione.Su un progetto di grandi dimensioni, questo potrebbe essere un notevole fastidio che era già abbastanza brutto quando guardando il codice sorgente in C, ma ancora peggio quando si fa forensics utilizzo misto di montaggio+codice sorgente e un raw stack di chiamate.

Quando di fronte a queste realtà, utilizzando m_ e tutti gli altri ungherese regole inizia a fare un po ' di senso anche con i costi di manutenzione a causa di quanto tempo sarebbe salva solo la ricerca di un simbolo tipo quando si guarda sconosciuto codice.Ora, naturalmente, abbiamo Intellisense e "Vai a Definizione", in modo che il principale risparmio di tempo la motivazione di questa convenzione di denominazione non c'è più.Non credo che c'è molto di fare il più, e io di solito cercare di andare con l' .Libreria di rete di linee guida, giusto per essere coerente e possibilmente guadagnare un po ' di più strumento di supporto.

Answer 23

Io sono certo di ottenere fiammato per questo, ma così è.

Si chiama Microsoft .Libreria di rete di linee guida, ma è davvero Brad Abrams s vistedocumento qui non ci sono altri punti di vista con validi motivi.

Le persone tendono ad andare con il punto di vista della maggioranza, piuttosto che avere delle ottime ragioni per uno stile.

Il punto importante è quello di valutare il perché di uno stile specifico è utilizzato e perché è preferito rispetto ad un altro stile - in altre parole, avere un motivo per la scelta di uno stile, non solo perché tutti dicono che è la cosa da fare - pensare per te stesso.

La ragione di base per l'utilizzo non in stile antico ungherese è stato l'uso di abbreviazioni che era diverso per ogni squadra e difficile da imparare - questo è facilmente risolvibile, non abbreviare.

Lo sviluppo di strumenti di modificare lo stile dovrebbe cambiare ciò che rende più senso - ma hanno un motivo solido per ogni elemento di stile.

Di seguito sono il mio stile di guida con le mie ragioni - sono sempre alla ricerca di modi per migliorare il mio stile per creare la più affidabile e più facile da mantenere il codice.

Variabile Convenzione Di Denominazione

Tutti noi abbiamo il nostro punto di vista sulla variabile convenzioni di denominazione.Ci sono molti stili diversi che aiutano a produrre facilmente gestibile codice di qualità - qualsiasi stile che sostiene la base essenziale informazioni su una variabile sono ok.I criteri per una specifica convenzione di denominazione deve essere, che aiuta nella produzione di codice che è affidabile e facilmente gestibile.Criteri che non devono essere utilizzati sono:E ' brutto Microsoft (es.Brad Abrams) dice di non usare quello stile Microsoft non produce sempre più affidabili codice basta guardare il bug in Expression Blend.È molto importante durante la lettura di codice che il nome di una variabile deve immediatamente trasmettere tre dati essenziali circa la variabile:e ' di ambito e ' il tipo di chiaramente capire su ciò che è utilizzato per Campo di applicazione:Microsoft consiglia di affidarsi totalmente a IntelliSense .IntelliSense è impressionante;tuttavia, non del mouse al di sopra di ogni variabile per vedere il suo ambito di applicazione e il tipo.Supponendo di una variabile in un ambito che non è in grado di causare gravi errori.Per esempio, se una variabile di riferimento è passato come parametro e si è alterato in ambito locale che modifica rimarranno dopo il metodo restituisce il che potrebbe non essere desiderato.Se un campo o una variabile statica è modificato in ambito locale, ma si pensa che si tratta di una variabile locale potrebbe causare un comportamento imprevisto.Pertanto, è estremamente importante essere in grado di guardare solo una variabile (non il mouse sopra) e immediatamente sapere che è ambito.

Il seguente stile per indicare il campo di applicazione è suggerito;tuttavia, uno stile che è perfettamente bene, purché chiaramente e coerentemente, indica che la variabile del campo di applicazione:m_ variabile del campo di p_ parametro passato al metodo s_ variabile statica variabile locale Tipo:Gravi errori possono verificarsi se uno crede di lavorare con un tipo specifico quando essi sono in realtà di lavoro con un diverso tipo - di nuovo, semplicemente non si mouse sopra mai variabile per determinare il tipo, siamo solo supporre che sappiamo di che tipo è e che è come gli errori vengono creati.

Abbreviazioni:Le abbreviazioni sono male, perché può significare cose diverse per diversi sviluppatori.Uno sviluppatore può pensare che un leader minuscole "s" significa stringa, mentre un altro può pensare significa integer.Le abbreviazioni sono un segno di lazy codifica - prendere un po ' di tempo, e digitare il nome completo di rendere chiaro lo sviluppatore che deve mantenere il codice.Per esempio, la differenza tra "str" e "stringa" è solo tre caratteri - non ci vuole molto più sforzo per rendere il codice di facile manutenzione.

Comune e chiara abbreviazioni per i tipi di dati predefiniti sono solo accettabile, ma deve essere standardizzata all'interno del team.

Auto Documentare Il Codice:Aggiunta di una descrizione chiara al nome della variabile che rende molto facile per un altro sviluppatore di leggere e comprendere il codice, il nome è quindi comprensibile che il team manager è in grado di leggere e comprendere il codice senza essere uno sviluppatore.

Ordine del Nome della Variabile Parti:L'ordine consigliato è di ambito-tipo-descrizione perché:IntelliSense raggruppa tutti simili gli ambiti e all'interno di ogni ambito di IntelliSense raggruppa tutti simili, il che rende le ricerche di facile provare a trovare una variabile in altro modo Rende molto facile vedere e comprendere la portata e di vedere e capire il tipo di È una cosa piuttosto comune in stile e facile da capire Passerà FxCop

Esempi:Ecco alcuni esempi:m_stringCustomerName p_stringCustomerDatabaseConnectionstring intNumberOfCustomerRecords o iNumberOfCustomerRecords o integerNumberOfCustomerRecords Queste semplici regole, sarà notevolmente migliorare il codice di affidabilità e manutenibilità.

Struttura Di Controllo Singola Riga Di Istruzioni Tutte le strutture di controllo (if, while, for, etc.) singola riga di istruzioni deve essere sempre avvolto con le parentesi graffe, perché è molto facile per aggiungere una nuova dichiarazione, non rendendosi conto che una citazione appartiene a una struttura di controllo che rompono la logica del codice, senza generare errori di compilazione.

Metodo Eccezione Di Avvolgimento Tutti i metodi dovrebbero essere avvolto con un esterno try-catch che trappola, fornire un luogo per recuperare, identificare, individuare, di registro, e prendere una decisione di lanciare o non.E ' l'imprevisto eccezione che causa le nostre applicazioni per crash - avvolgendo ogni metodo di cattura tutte le eccezioni non gestite possiamo garantire l'identificazione e la registrazione di tutte le eccezioni e prevenire la nostra applicazione, da sempre in crash.Ci vuole un po ' di lavoro in più, ma il risultato è valsa la pena.

Rientro Il rientro non è un grosso problema;tuttavia, quattro spazi e non l'uso di schede è suggerito.Se il codice è stampato, la prima scheda stampante di solito di default è 8 spazi.Diversi sviluppatori tendono ad usare la scheda diversa dimensione.Microsoft codice di solito è rientrata 4 spazio, e quindi se si utilizza qualsiasi codice di Microsoft e per altri usi di 4 spazi, quindi il codice deve essere riformattato.Quattro spazi che rende facile e coerente.

Answer 24

Se non codifica di sotto di una particolare disciplina, si dovrebbe continuare a utilizzare il tuo attuale m_ notazione e modificarla, se il progetto di linee guida di codifica dice così.

Answer 25

Essere funzionale.

• Non usare variabili globali.
• Non utilizzare variabili statiche.
• Non utilizzare le variabili membro.

Se è davvero necessario, ma solo se è davvero necessario, utilizzare una e una sola variabile per accedere alla tua applicazione / ambiente.