Perché Microsoft ha creato parametri, variabili locali e campi privati hanno la stessa convenzione di denominazione dei nomi?

Le convenzioni di denominazione originali avevano un prefisso m_ per i membri della classe, questo è stato ridotto a semplice trattino di sottolineatura. Vedrai molto vecchio codice C # Microsoft usando un prefisso di sottolineatura. Tuttavia, ho sentito in un Tech Ed una volta che un underscore principale non è conforme a CLS. Presumo che questo sia il motivo per cui sono passati al più semplice schema one-name-fits-all. In passato (non sono sicuro) i nomi non sensibili alla distinzione tra maiuscole e minuscole di VB.Net non erano compatibili con CLS.

Per quel che vale, uso ancora il trattino di sottolineatura principale per i membri della classe. Anche se puoi disambiguare usando questo (questo.name in opposizione al nome), gli errori continuano a essere superati.

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

local e parameter sono denominate 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 specifica utilizzare un _ prima delle variabili private, sebbene l'autore affermi che _ è un po 'controverso e che Microsoft raccomanda di non farlo.

Wikipedia afferma che in C e C ++

Names beginning with double underscore or an underscore and a capital letter are reserved for implementation (compiler, standard library) and should not be used (e.g. __reserved or _Reserved).

quindi forse questa era la ragione alla base della raccomandazione di Microsoft contro questo, 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 possa farlo a meno che qualcuno che ha preso parte alla creazione degli standard abbia visto questa domanda.

Molte persone creano le proprie convenzioni anteponendo le variabili di istanza con _ o m_ , ma davvero non penso 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, puoi utilizzare il prefisso this. 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, per impostazione predefinita Visual Studio ti aiuterà con Intellisense:

(Ilpop-uppotrebbeancoraesseredisegnatodaReSharper,maReSharpernonaggiungenullaallefunzionalitàdiIntellisenseincorporato,quindimentrequellodiriservapotrebbesembrareunpo'diverso,avràcomunqueentrambeleopzionilìdentro.)

Puoiancheutilizzarestrumentidianalisidelcodicecome FxCop e StyleCop per aiutarti a cogliere potenziali problemi con la denominazione e l'ambito delle variabili.

Why didn't Microsoft's standard keep these different?

I membri di Microsoft hanno scritto un libro chiamato Framework Design Guidelines che spiegava una serie di convenzioni, incluso il motivo per cui alcune le cose erano camel cased , e altre erano pascal cased .

Modifica (aggiungendo dettagli dal libro):

Nel libro menzionano gli studi sull'usabilità e alcune delle lezioni apprese dall'acquisizione del gruppo Turbo Pascal. Inoltre, anche se non tutte le lingue sono sensibili al maiuscolo / minuscolo (come VB), altre sono (come C #), quindi si dovrebbe essere coerenti nella denominazione. Non si può dipendere dalle differenze nel caso solo per distinguere gli oggetti. Se ci si attiene alle convenzioni usate dal resto del framework, questo porterà a una minore confusione da parte degli sviluppatori.

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

camelCasing è per i nomi dei parametri.
PascalCasing è per namespace, tipo e nomi dei membri. Nel caso in cui vi siano sigle di 2 lettere come parte del nome, tenerle in maiuscolo insieme, ad esempio IOStream .

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

Perché sono abbastanza distinguibili in quanto dipendono dal contesto in cui sono scritti.

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. Davvero non compro l'argomento che è necessario anteporre il membro quando puoi usare this per distinguerlo da una variabile locale con un nome simile, altrimenti non è necessario.

• Una variabile locale viene 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 ottieni tutti questi tipi di variabili confuse o mescolate insieme, dovresti davvero pensare più alla progettazione del codice per renderla più leggibile o rilevabile. Dai loro nomi migliori e più descrittivi rispetto a myInteger .

Non posso rispondere alla tua domanda sugli standard Microsoft. Se si desidera uno standard per differenziare queste cose, lo standard che utilizzo per i parametri PL / SQL ha come prefisso il nome del parametro con in_ , out_ , io_ , per i parametri in entrata, in uscita e in uscita . Le variabili che sono locali a una funzione hanno come prefisso un v_ .

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

_varName

o

mVarName

Proprio come hanno fatto notare altre persone, di solito si può dire quale sia l'ambito in cui viene utilizzato l'oggetto. In realtà non è possibile avere il parametro e la variabile locale nello stesso ambito e se si desidera la variabile privata, utilizzare this.myInteger. Quindi non credo che Microsoft si preoccupi troppo di questo perché puoi facilmente distinguere tra loro se vuoi.

Ma detto questo, sono un po 'sorpreso che nessuno abbia ancora detto questo, ma dimentico di Microsoft e delle loro convenzioni sui nomi (beh, qualcuno potrebbe averlo detto ormai perché dovevo correre a una riunione e lasciare questo aprire senza inviarlo). La notazione ungherese era anche una convenzione di denominazione iniziata in Microsoft (o era Xerox? Non ricordo mai quando Simonyi ha inventato questo). Non riesco a pensare a nessuno che io sappia che non maledica il nome della notazione ungherese fino ad oggi. Siamo diventati così infastiditi dal posto in cui ho lavorato che abbiamo inventato il nostro standard che abbiamo usato internamente. Ha più senso per noi e ha velocizzato un po 'il nostro lavoro (in realtà era abbastanza vicino a ciò che Microsoft suggerisce ora, ma tutto era un caso pasquale con l'eccezione delle variabili private).

Detto questo, lo standard più recente utilizzato da Microsoft (la combinazione di caso cammello e caso pascal) non è male. Ma se a te e ai tuoi colleghi non piace, venite con i vostri standard (collettivamente è il migliore). Questo ovviamente dipende dal fatto che la tua azienda abbia già una serie di standard. Se lo fanno, attenersi a loro. Altrimenti, preparati a ciò che funziona per te e per i tuoi colleghi. Resta logico. '

Poiché Aaronaught ha chiesto la citazione di Charles Simonyi e della notazione ungherese: link

link

link

link

link

link

Gli ultimi due sono solo esempi di notazione ungherese e il collegamento di ootips è solo alcune citazioni riguardanti alcune opinioni sull'argomento. Si noti che esiste anche la notazione ungherese di sistema ma che, per quanto ne so, è arrivata alla popolarità dai programmatori Microsoft (anche se a differenza di Simonyi per la variazione delle app, non so chi).