Perché Microsoft ha impostato parametri, variabili locali e campi privati ​​con la stessa convenzione di denominazione?

Ho fatto questa domanda un po 'di tempo fa: come si chiamano le variabili private in C #?

In una delle risposte, sono stato indicato la pagina MSDN di Microsoft che mostra che i campi / variabili privati ​​dovrebbero essere nominati in questo modo:

private int myInteger;

Ma un parametro sarebbe:

void SomeMethod(int myInteger)

e una variabile locale sarebbe così:

int myInteger;

Quindi quando li fai riferimento in questo modo

myInteger = 10;

non hai modo di sapere di chi stai parlando.

Ora sto iniziando un nuovo progetto e uno dei miei colleghi mi sta chiedendo perché non facciamo qualcosa per differenziare almeno alcuni di questi.

Mi chiedo la stessa cosa. Perché lo standard di Microsoft non ha mantenuto queste differenze?

Le convenzioni di denominazione originali avevano un prefisso m_ per i membri della classe, che si riduceva a un semplice trattino basso. Vedrai un sacco di codice Microsoft C # precedente usando un prefisso di sottolineatura. Tuttavia, ho sentito in un Tech Ed una volta che un carattere di sottolineatura principale non è conforme a CLS. Presumo che questo sia il motivo per cui si sono spostati nel più semplice schema a nome unico adatto a tutti. Prima (non sono sicuro) che i nomi insensibili alle maiuscole e minuscole di VB.Net non fossero conformi a CLS.

Per quello che vale, uso ancora il carattere di sottolineatura principale per i membri della classe. Anche se puoi disambiguare usando questo (this.name invece di name), i bug riescono comunque a superare.

Non devi fare tutto ciò che MS ti dice di fare.

locale le parametervariabili sono chiamate allo stesso modo perché il loro ambito è lo stesso

Per quanto riguarda le variabili private, ci sono opinioni diverse su questo. Ho sempre usato gli standard trovati qui , che specificano l'uso di una _delle variabili private precedenti, anche se l'autore afferma che _è un po 'controverso e che Microsoft sconsiglia.

Wikipedia afferma che in C e C ++

I nomi che iniziano con un doppio trattino basso o un trattino basso e una lettera maiuscola sono riservati per l'implementazione (compilatore, libreria standard) e non devono essere utilizzati (ad es. __Reserved o _Reserved).

quindi forse questo è stato il motivo per cui Microsoft lo ha sconsigliato, anche se è abbastanza noto che molti sviluppatori Microsoft usano comunque un _prefisso per le loro variabili private.

Non posso dirti con certezza perché non li hanno tenuti diversi. È probabile che nessuno ci riesca a meno che qualcuno che abbia preso parte alla creazione degli standard capiti di vedere questa domanda.

Molte persone creano le proprie convenzioni anteponendo le variabili di istanza con _o m_, ma non credo davvero che importi. Puoi dedurre molto dal contesto e gli IDE in questi giorni sono abbastanza intelligenti da aiutarti. Visual Studio con l'addon ReSharper, ad esempio, mostrerà variabili locali e variabili di istanza in diversi colori.

Se è davvero importante distinguere tra i due ambiti, è possibile utilizzare il this.prefisso per fare riferimento alla variabile di istanza:

public class Test
{
    private int myInteger;

    void SomeMethod(int myInteger)
    {
        this.myInteger = 10; // sets instance variable to 10
        myInteger = 10; // does not affect the instance variable.
    }
}

Senza altri plugin, Visual Studio ti aiuterà di default con Intellisense:

(Il pop-up può ancora essere disegnato da ReSharper lì, ma ReSharper non aggiunge nulla alle caratteristiche di Intellisense integrato, quindi mentre quello di serie potrebbe apparire un po 'diverso, avrà comunque entrambe le opzioni. )

Puoi anche utilizzare strumenti di analisi del codice come FxCop e StyleCop per aiutarti a rilevare potenziali problemi con denominazione e ambito variabili.

Perché lo standard di Microsoft non ha mantenuto queste differenze?

La gente di Microsoft ha scritto un libro chiamato Framework Design Guidelines che ha spiegato una serie di convenzioni, incluso il motivo per cui alcune cose sono state incastonate in cammello e altre sono state incapsulate in pascal .

Modifica (aggiungendo dettagli dal libro):

Nel libro menzionano lo studio dell'usabilità e alcune delle lezioni apprese dall'acquisizione del gruppo Turbo Pascal. Inoltre, sebbene non tutte le lingue facciano distinzione tra maiuscole e minuscole (come VB), altre lo sono (come C #), quindi si dovrebbe essere coerenti nella denominazione. Non si può dipendere dalle differenze nel solo caso per distinguere gli elementi. Se si rispettano le convenzioni utilizzate dal resto del framework, si creerà meno confusione da parte degli sviluppatori.

Capitolo 3, Linee guida per la denominazione.
La sezione 3.1 è convenzioni di capitalizzazione.

camelCasingè per i nomi dei parametri.
PascalCasingè per spazio dei nomi, tipo e nomi dei membri. Nel caso in cui ci siano acronimi di 2 lettere come parte del nome, tenerli insieme, come ad esempio IOStream.

La sezione 3.5 tratta le classi, le strutture e le interfacce di denominazione.
La sezione 3.6 tratta i membri del tipo di denominazione.
La sezione 3.7 tratta i parametri di denominazione.

Perché sono piuttosto distinguibili in quanto dipendono dal contesto in cui sono scritte.

Ad esempio, hai mai usato un parametro come variabile membro? O una variabile locale come parametro? Che ne dici di una variabile membro come locale?

• Tutte le variabili membro sono nel "corpo" di una classe. Non compro davvero l'argomento secondo cui devi aggiungere il prefisso al membro quando puoi usarlo thisper distinguerlo da una variabile locale con un nome simile, altrimenti non è necessario.

• Una variabile locale è anche definita solo nell'ambito di un metodo o nell'ambito di un blocco di codice.

• Un parametro è sempre definito nella firma del metodo.

Se si confondono o si mescolano tutti questi tipi di variabili, si dovrebbe davvero pensare di più alla progettazione del codice per renderla più leggibile o rilevabile. Dai loro nomi migliori e più auto-descrittivi di myInteger.

Non posso rispondere alla tua domanda sugli standard di Microsoft. Se si desidera uno standard per differenziare queste cose, l'uso standard che per i parametri di PL / SQL è prefisso il nome del parametro con in_, out_, io_, per i parametri in-, OUT-, e-OUT-. Le variabili locali a una funzione hanno come prefisso a v_.

La maggior parte delle aziende che conosco hanno standard di codifica che specificano un carattere di sottolineatura o la lettera minuscola m (per "membro" presumo) come prefisso per le loro variabili membro.

Così

_varName

o

mVarName

Proprio come altre persone hanno sottolineato, di solito si può dire quale sia quale ambito viene utilizzato l'oggetto. In realtà non puoi avere il parametro e la variabile locale nello stesso ambito e se vuoi la variabile privata, usa this.myInteger. Quindi non penso che Microsoft sia preoccupata troppo per questo, poiché puoi facilmente distinguerli tra loro, se lo desideri.

Detto questo, sono un po 'sorpreso che nessuno lo abbia ancora detto, ma dimentica di Microsoft e delle loro convenzioni di denominazione (beh, qualcuno potrebbe averlo già detto, dato che dovevo correre a una riunione e lasciarlo aperto senza presentare esso). Anche la notazione ungherese era una convenzione di denominazione avviata da Microsoft (o era Xerox? Non riesco mai a ricordare quando Simonyi l'ha inventata). Non riesco a pensare a nessuno che conosco che non maledica il nome della notazione ungherese fino ad oggi. Ci siamo così infastiditi nel posto in cui ho lavorato che abbiamo escogitato il nostro standard che abbiamo usato internamente. Per noi ha avuto più senso e ha accelerato un po 'il nostro lavoro (in realtà era abbastanza vicino a ciò che Microsoft suggerisce ora, ma tutto era un caso pasquale ad eccezione delle variabili private).

Detto questo, lo standard più recente utilizzato da Microsoft (la combinazione di custodia cammello e custodia pascal) non è poi così male. Ma se a te e ai tuoi colleghi non piace, inventate il vostro set di standard (collettivamente è il migliore). Questo ovviamente dipende dal fatto che la vostra azienda abbia già una serie di standard. Se lo fanno, attenersi a loro. Altrimenti inventati ciò che funziona per te e i tuoi colleghi. Mantienilo logico. '

Da quando Aaronaught ha chiesto la citazione di Charles Simonyi e della Notazione ungherese: http://en.wikipedia.org/wiki/Charles_Simonyi

http://en.wikipedia.org/wiki/Hungarian_notation

http://msdn.microsoft.com/en-us/library/aa260976(v=VS.60).aspx

http://ootips.org/hungarian-notation.html

http://www.hitmill.com/programming/vb/Hungarian.html

http://web.mst.edu/~cpp/common/hungarian.html

Gli ultimi due sono solo esempi di notazione ungherese e il link ootips è solo alcune citazioni relative ad alcune opinioni sull'argomento. Si noti che esiste anche la Notazione ungherese di sistema, ma che, per quanto ne so, è diventata popolare anche dai programmatori Microsoft (anche se a differenza di Simonyi per la variante di app, non so chi).