La notazione ungherese di Systems è ancora una pratica utile? [chiuso]


23

Ho cercato nel forum, ma non sono riuscito a trovare le risposte perché dovrebbe essere evitato, solo perché non è un proiettile d'argento. Quindi non penso che questa domanda sia un duplicato.

C'è un motivo valido per cui dovrei disimparare i sistemi ungheresi a cui sono abituato?

Finora vedo i seguenti vantaggi nell'usarlo:

  • Denominazione variabile coerente
  • Vedi il tipo senza cercare (intellisense è morto / indicizza metà del tempo, quindi è ancora un motivo valido)
  • La semantica può ancora essere inserita nella seconda parte del nome

E i seguenti aspetti negativi:

  • Infastidisce alcune persone (non ho idea del perché)
  • Se il tipo viene modificato, il tipo potrebbe non corrispondere al nome della variabile (non credo che sia un motivo valido, i tipi vengono modificati raramente e hai "rinomina tutto")

Quindi perché:

vector<string> vecCityNames;
wstring strCity = L"abc";
//more code here
vecCityNames.push_back(strCity);

è peggio di:

vector<string> cityNames;
wstring city = L"abc";
//more code here
cityNames.push_back(city);//Are we pushing back int on a queue? Float on a stack? Something else?

4
se intellisense è morto, il tuo codice non è valido. Se non è valido, perché supporre che il nome della variabile sia corretto?
Bubblewrap,

6
@Bubblewrap: la maggior parte delle implementazioni di intellisense impantanano occasionalmente per 3 secondi, anche con un codice valido. E a volte non funzionano affatto, anche se compilazioni e collegamenti di codice. Stiamo parlando di progetti di dimensioni ragionevoli.
Coder

9
non dovrebbe vectCityNamesessere vectStringCityNamescosì tanto per la tua argomentazione coerente, e questa "domanda" è più rantesca di qualsiasi altra cosa, hai la tua decisione, questo dovrebbe essere chiuso.

8
Quale ritieni sia un motivo "valido"?
Adam Lear

15
Non credo che il tuo secondo esempio sia confuso nel modo in cui il tuo commento lo indica. Il significato di cityNames.push_back(city)è abbastanza chiaro. È un elenco di nomi di città e ne stai aggiungendo uno.
Chris Burt-Brown,

Risposte:


62

Lo usavo (molti anni fa) e non lo faccio più. Il motivo principale è che è superfluo nei linguaggi OO con una digitazione forte (C ++, Java) che mi è capitato di aver usato gran parte della mia carriera. In queste lingue, se definisco bene i miei tipi, il compilatore può e imporrà la sicurezza dei tipi per me. Quindi qualsiasi prefisso di denominazione è solo un disordine che allunga i nomi, quindi è più difficile da leggere e da cercare.

In qualsiasi programma OO ben scritto, la maggior parte delle variabili sono (riferimenti a) tipi definiti dall'utente. Se aggiungi questi prefissi con lo stesso tag generale (come oper "oggetto"), non ne trarrai alcun vantaggio, ma solo gli svantaggi. Se tuttavia li prefiggi con tag specifici del tipo, entri nel labirinto di cercare di trovare abbreviazioni diverse per mille tipi diversi con nomi spesso simili * e di ricordarti di cambiarli tutti quando un tipo o il suo nome cambiano (che è non è affatto raro in un programma ben mantenuto).

Naturalmente, questo non si applica alle lingue non OO e potrebbe non applicarsi alle lingue debolmente e / o tipizzate in modo dinamico (non ho esperienza con queste, a parte C). Né per editor / IDE non ottimali senza un IntelliSense utilizzabile (o il suo equivalente locale). E questi sono solo i miei 2 centesimi. Quindi, se la notazione ungherese funziona per il tuo team e il tuo progetto, provaci. L'importante è concordare su questo (così come su uno stile di codifica coerente in generale) prima dell'inizio del progetto e mantenerlo coerente in ogni momento.

* Solo un breve elenco dal nostro progetto attuale: abbiamo Charge, ChargeBreakdown, ChargeCalculator, ChargeDAO,ChargeDTO , ChargeLineHelper, ChargeMaps, ChargePaire ChargeType, tra gli altri. Inoltre abbiamo anche Contracts, Countries, Checkouts, Checkins ... e questa è solo la lettera C, in un progetto che probabilmente non verrebbe nemmeno chiamato "ragionevolmente dimensionato" dall'OP.


Disclaimer: in realtà sono ungherese, quindi credo di poter parlare di questo problema con autorità ;-)


"Digitazione forte" - Se C ++ avesse un sistema di tipi veramente forte, non dovresti incorporare i tipi nel nome della variabile come un hack.
Michael Burge,

19
@MichaelBurge: questo è il punto. Non devi Perché lo fa.
DeadMG

8
+1 per il punto sui tipi definiti dall'utente. L'uso di variabili nominate iPoso fAmountpuò essere tollerabile, ma prova a lavorare su una base di codice in cui a ogni variabile oggetto viene assegnato un prefisso ridondante di sei lettere che ti informa solo che si tratta di un "puntatore a una struttura".

2
Vorrei fare un'eccezione per le GUI in cui è necessario memorizzare un handle per ciascun controllo oltre al suo valore, quindi text e hText anziché pensare a un nome diverso per la casella di immissione. Particolarmente importante nei sistemi in cui la maniglia è solo un tipo int, non un tipo speciale.
Martin Beckett,

1
Immagino che un posto importante in cui Java avrebbe dovuto raccomandare l'uso della notazione ungherese è quello di distinguere tra riferimenti a casi che possono essere mutati ma mai condivisi (ad esempio, char[]trattenuto da a StringBuilder) e riferimenti a casi che non possono essere mutati, ma può essere condiviso con cose che non le mutano (ad esempio, char[]trattenuto da String, che può essere condiviso tra più Stringistanze). Entrambi i campi sono dello stesso tipo char[], ma contengono elementi molto diversi. Molti bug relativi alla mutabilità derivano da ...
supercat,

35

Perché è std::vector<string> vecCityNames;cattivo?

Il problema con la notazione ungherese in quanto viene solitamente utilizzato che, se la profilazione mostra che i nomi delle città dovrebbero piuttosto essere conservati in a std::deque , tutti i nomi delle variabili che si riferiscono a un oggetto di quel tipo avranno improvvisamente un nome fuorviante.

Rinominerai quindi tutte le tue variabili? Hai mai provato a farlo in un grande progetto? Con l'aiuto di Murphy (e il ragazzo è incredibilmente utile lì) qualcuno da qualche parte avrà sicuramente usato variabili chiamate qualcosa di similedeqCityNames , facendo che le tue modifiche rompano la build, lasciandoti seduto per ore a giocherellare con il codice che, per mezzo decennio, nessuno ha osato nemmeno guardare a, per paura di essere morso da una bestia velenosa.

Da quello che so, tuttavia, il modo in cui Charles Simonyi ha inventato l'ungherese, il prefisso indicava l' uso semantico delle variabili , piuttosto che il suo tipo sintattico . Cioè, il prefisso corretto per il tuo elenco di nomi di città, indipendentemente dal tipo in cui è implementato, probabilmente sarebbe listCityNames(olstCityNames , se listnon è abbastanza criptico per te).

Ma ritengo che quel prefisso sia del tutto superfluo, perché il plurale ("nomi") indica già che è un mucchio di città. In conclusione: quando si selezionano i propri identificativi con cura, raramente è necessaria la notazione ungherese. OTOH, il modo in cui viene comunemente usato, a lungo termine, sta effettivamente danneggiando il codice.


6
@Coder: il tipo viene utilizzato in tutto il progetto e tutte le variabili di questo tipo avranno il prefisso. Dovrai rinominare non una variabile globale, ma centinaia di quelle locali.
sabato

7
Dovresti aggiungere un link al post sul blog di Joel Spolsky in cui offre la sua spiegazione del perché l'utilizzo di un tipo variabile per ottenere una notifica ungherese è un fraintendimento di cosa si tratta. Il tuo è buono ma alcune persone potrebbero essere alla ricerca di qualcosa di più autorevole e potresti usarlo per eseguire il backup del tuo caso. joelonsoftware.com/articles/Wrong.html
Shane Wealti,

2
@Coder: Sfortunatamente, typedefè uno strumento seriamente sottovalutato
sbi,

4
@Shane: ho scritto la mia opinione in merito. Se ciò dovesse coincidere con quello di Joel, allora per me va bene, perché apprezzo le sue opinioni anche se non sono d'accordo con alcune di esse. Ma non vedo la necessità di fare appello ad altre "autorità" per sostenere la mia opinione quando questa si basa su più di un decennio di esperienza conquistata duramente. È bello che tu abbia pubblicato quel link, tuttavia, è sempre bello vedere le opinioni degli altri con cui confrontarle.
sbi

4
Molto tempo fa, ero il ragazzo CVS del negozio e uno dei principali sviluppatori ha cambiato le iniziali (chirurgia del cambio di sesso, ecc., E il suo nome e il suo nome non avevano le stesse iniziali). Ogni volta che toccava un file (o uno simile), cambiava tutte le sue iniziali nella nuova forma. L'ho trovato estremamente fastidioso, dato che avremmo avuto ogni sorta di piccoli cambiamenti nelle caratteristiche storiche, ed è stato difficile capire cosa fosse effettivamente cambiato e perché. Passa vecCityNamesa deqCityNamesin poche centinaia di file e fai la stessa cosa.
David Thornley,

15

Per qualsiasi motivo, le risposte esistenti qui sembrano danzare attorno alla logica della notazione ungherese, senza dichiararla apertamente. La notazione ungherese è utile per aggiungere informazioni sul tipo (in un senso teorico del tipo ) quando sarebbe difficile farlo nella lingua stessa . Come succede, di solito non è così difficile usare il C ++ o il sistema di tipi di Java in modo tale che la notazione ungherese (come di solito descritta) sia completamente superflua, e questo è probabilmente ciò che ha portato al contraccolpo contro di esso - aggiunge il lavoro del programmatore per mantenere quelle annotazioni in tutti i nostri valori variabili, ma fornisce un valore aggiuntivo quasi da nulla (e può persino causare danni, poiché il codice appare più disordinato).

D'altra parte, se si limita l'uso della notazione ungherese per digitare informazioni (di nuovo, in un senso teorico ) che non ènaturalmente incapsulato dalla lingua, quindi può essere molto utile. Ad esempio, C e C ++ passano i riferimenti di matrice come tipi di puntatore, ma i riferimenti di matrice e i puntatori hanno diverse operazioni che devono essere eseguite su di essi: le matrici possono essere indicizzate oltre il primo elemento, mentre i puntatori non dovrebbero. Si tratta di informazioni utili che vanno perse al sistema dei tipi non appena un array viene passato a una funzione come argomento. Pertanto, nel nostro gruppo abbiamo adottato le annotazioni dei nomi delle variabili nel codice C e C ++ per distinguere se una variabile del puntatore è in realtà un puntatore a un singolo elemento o un puntatore a un array. L'adozione di questa convenzione è stata in parte responsabile di una grande riduzione del verificarsi di problemi di corruzione della memoria nella nostra base di codice.


Ciò che ha fatto fallire l'ungherese è stato l'uso improprio (da parte del team WinAPI) per codificare il tipo sintattico di una variabile , piuttosto che il suo significato semantico . (Pensa dwvs cb..) Non è che la sua forma originale sarebbe meno utile nei linguaggi OO: un indice è ancora un indice, anche se archiviato in un tipo di classe piuttosto che in un built-in.
sabato

1
+1 per sottolineare che il vero argomento qui riguarda la teoria dei tipi. La notazione ungherese è una tecnica per aumentare il sistema dei tipi con informazioni aggiuntive e come tale dovrebbe essere confrontata e contrastata con altre tecniche per aumentare il sistema dei tipi (ad esempio modelli, typedef, ecc.), Piuttosto che essere discussa sui suoi meriti estetici (o mancanza di ciò).
Daniel Pryden,

1
La domanda riguarda in particolare "Sistemi ungheresi", inutile duplicazione del tipo dichiarato, senza ulteriori informazioni semantiche. Potrebbe essere utile utilizzare il concetto originale di "notazione ungherese" di tag semantici per fornire informazioni oltre a quelle consentite dalla sintassi della lingua (in alcune lingue, incluso C, sebbene non C ++, dove è possibile farlo in modo più affidabile con tipi definiti dall'utente ), ma non è questo il problema.
Mike Seymour,

10

Infastidisce alcune persone (non ho idea del perché)

Il motivo per cui mi dà fastidio è che è un piccolo aumento di velocità su ogni singolo identificativo che rallenta la mia scansione visiva del codice. Si tratta di mAs se si desidera avere z q Per leggere l'inglese cText Mi piace questo.


9

L'odio è una parola troppo forte, IMO. Puoi scrivere il tuo codice come preferisci; Preferisco semplicemente non usare la notazione ungherese nel mio codice e, data la scelta, preferirei anche non doverlo leggere o lavorare con esso nel codice di altre persone.

Hai chiesto perché alcune persone trovano fastidiosa la notazione ungherese. Non posso parlare per gli altri, ma i motivi che mi infastidiscono sono:

  1. È brutto. L'ungherese prende nomi perfettamente ragionevoli e antepone ciò che equivale a un codice. Una volta che hai interiorizzato questo codice, sono sicuro che abbia perfettamente senso, ma per chi non lo sapesse sembra che qualcuno abbia scatenato il mangler del nome C ++ sul mio codice sorgente.

  2. È ridondante. La dichiarazione di una variabile stabilisce il suo tipo; Non sento la necessità di ripetere tali informazioni nel nome della variabile. Questo non è vero in tutte le lingue: in Perl, ad esempio, sigilli come @ o $ anteposti al nome della variabile definiscono essenzialmente il tipo di variabile, quindi non hai altra scelta che usarli.

  3. Risolve un problema che non ho. I metodi e le funzioni non dovrebbero essere così lunghi che devi cercare di trovare la dichiarazione di una variabile o parametro locale, e non dovrebbero coinvolgere così tante variabili che hai difficoltà a tenere traccia di cosa. Dichiarare le variabili locali vicine al codice che le utilizza aiuta anche a questo proposito. I compilatori C del passato richiedevano che tutte le variabili locali fossero dichiarate all'inizio della funzione, ma questa limitazione è stata rimossa molto tempo fa.

  4. È incompleta. La notazione ungherese è stata inventata per una lingua (BCPL) che non aveva un sistema di tipi e successivamente è stata ampiamente utilizzata in una lingua (C) che aveva un numero piuttosto limitato di tipi nativi. IMO, non funziona bene con linguaggi come C ++ o Java che hanno sistemi di tipo estesi. Perché dovrei usare un prefisso per indicare il tipo di una variabile che è un tipo nativo, come char [], ma non uno che è una classe? In alternativa, se inizio a inventare prefissi come vecper le classi, finirò con una grande gerarchia di prefissi parallela alla mia gerarchia di classi. Se questo ti piace, sei il benvenuto; solo a pensarci mi sta facendo venire il mal di testa.

  5. È ambiguo , almeno per come lo capisco. Qual è la differenza tra szFooe pszFoo? Il primo è una stringa con terminazione zero e il secondo è un puntatore a una stringa con terminazione zero. Ma in C o C ++, per quanto ne so, ogni variabile stringa è effettivamente un puntatore, quindi sono uguali o no? Quale dovrei usare? La risposta effettiva non conta davvero - il punto è che non riesco a discernere la risposta usando la stessa notazione che dovrebbe aiutarmi a evitare questo tipo di domande. La dichiarazione della variabile, d'altra parte, deve essere inequivocabile perché è ciò che utilizza il compilatore.

Queste sono le cose che mi infastidiscono della notazione ungherese. Anche come gruppo, tuttavia, non credo che spieghino appieno perché l'ungherese sia stato in gran parte abbandonato. Ecco i tre principali motivi per cui la maggior parte dei programmatori non usa l'ungherese:

  1. Non c'è motivo convincente per usarlo. Vedi gli articoli 3 e 4 sopra. Probabilmente potrei vivere con i fastidi se l'ungherese offrisse un grande vantaggio rispetto al non usare l'ungherese, ma non ne vedo uno, e apparentemente la maggior parte delle altre persone non lo fanno neanche. Forse la cosa migliore dell'ungherese era che si trattava di una convenzione ampiamente usata, e se rimanessi fedele all'uso standard, potresti ragionevolmente aspettarti che altri programmatori con competenze simili siano in grado di capire la notazione.

  2. Maggiore influenza delle aziende che non sono Microsoft. Probabilmente è giusto affermare che la maggior parte dei programmatori che hanno adottato la notazione ungherese lo hanno fatto perché è così che Microsoft ha scritto il codice ed è spesso più semplice seguire il flusso. Aziende come Google e Apple hanno sfere di influenza molto, molto più grandi ora che in passato, e più programmatori che mai stanno adottando gli stili di quelle aziende e di altre che evitano per lo più l'ungherese. (È giusto sottolineare che si vedono ancora alcuni resti, ad esempio sia Google che Apple usano spesso un prefisso "k" per i nomi costanti.)

  3. La stessa Microsoft ha abbandonato l'ungherese. Se controlli la sezione Convenzioni generali di denominazione di Microsoft nelle linee guida per la codifica, scoprirai che è scritto in grassetto: non usare la notazione ungherese.

Di conseguenza, un motivo valido per smettere di usare la notazione ungherese è:

La popolarità della notazione ungherese è diminuita al punto che la convenzione non è più utile. Oggigiorno molti meno programmatori usano o capiscono l'ungherese e la convenzione è quindi molto meno efficace nel trasmettere le informazioni che dovrebbe. Se lo trovi un modo utile per scrivere il codice nei tuoi progetti personali, allora ci sono poche ragioni per smettere. Tuttavia, se stai scrivendo codice come parte di un team che non usa l'ungherese, potrebbe diventare un muro tra te e il resto del team anziché una strategia di comunicazione di successo.


"Qual è la differenza tra szFooe pszFoo"? Uno è char*, l'altro char**, mi ci sono voluti 0,25 secondi per dire la differenza. Prova a batterlo con Intellisense.
Coder

2
@Coder, pnFooprobabilmente lo sarebbe int*, no int**, quindi devi sapere che szsignifica anche un puntatore. Sono sicuro che non è un grosso problema per il numero limitato di tipi che hanno stabilito prefissi ungheresi, ma in qualsiasi progetto di grandi dimensioni ha definito un numero di tipi a migliaia. Non conosco Intellisense, ma gli IDE sono costantemente migliorati negli ultimi 25 anni e mi aspetto che questa tendenza continui.
Caleb,

8

Finora vedo i seguenti vantaggi nell'usarlo:

  • Denominazione variabile coerente

Se assegno tutte le mie variabili ai personaggi di The Simpsons, anche questo è coerente, ma è un vantaggio?

  • Vedi il tipo senza cercare (intellisense è morto / indicizza metà del tempo, quindi è ancora un motivo valido)

Questo è l'unico motivo valido, basato sulla debolezza di uno strumento specifico ...

  • La semantica può ancora essere inserita nella seconda parte del nome

Questo non è un vantaggio; stai semplicemente rivendicando l'assenza di un ( enorme ) aspetto negativo.


6

L'IDE mi dirà banalmente quale sia il tipo di una variabile quando ci passo sopra con il mouse. Quindi perché preoccuparsi di duplicare tali informazioni? Fondamentalmente, la Notazione ungherese di sistemi è una violazione di DRY, con tutte le insidie ​​ad essa associate. Quando tali informazioni sono banalmente accessibili in un ambiente moderno, non c'è motivo di pagare quel prezzo.

La coerenza non è un vantaggio in sé. Non dar loro un nome con il tipo è anche coerente. Avresti incoerenza solo se solo alcune variabili avessero i loro tipi nel nome. E impacchettare la semantica nella seconda parte è semplicemente "Beh, non è poi così male", tutti gli altri usano il nome intero per la semantica. Non hai alcun vantaggio reale elencato.


4
"L'IDE mi dirà banalmente quale sia il tipo di una variabile quando ci passo sopra con il mouse.", Ciao mondo, sì. Sui progetti più grandi trovo questa funzionalità estremamente inaffidabile / lenta. ctrl + spazio, ctrl + spazio, ctrl + spazio, ctrl + spazio, ctrl + spazio, no go ...
Coder

3
Ottieni un nuovo IDE. O un SSD, che fa miracoli. Oppure includi solo le intestazioni meno inutili.
DeadMG

1
Anche se l'IDE è troppo lento quando mostra il tipo di una variabile, o se semplicemente non è in grado di farlo, i metodi / le funzioni dovrebbero essere brevi, in modo che la dichiarazione di una variabile non sarà mai molto lontana dal suo uso.
Kevin Panko,

6

Un altro punto con le forme tradizionali di notazione ungherese è che di solito sono prefissi. ci sono 2 problemi qui:

1) Un lettore umano vorrebbe generalmente prima le informazioni più importanti, nella maggior parte delle forme di ungherese le informazioni codificate sono probabilmente meno importanti del nome stesso.

2) I prefissi effettuano l'ordinamento lessicale, quindi se ad esempio si intende utilizzare un prefisso per indicare interfacce o classi e il proprio IDE fornisce un elenco ordinato di queste, le classi / interfacce correlate verranno separate in questo elenco.


2

Chiaramente, questo si riduce alle opinioni, quindi sarà difficile lavorare con i fatti qui. Personalmente, trovo che l'argomento per la notazione ungherese sia un po 'sottile in linguaggi fortemente tipizzati e orientati agli oggetti. Nella mia esperienza, le applicazioni OO tendono a gestire la complessità mantenendo le classi coerenti e concise e lo stesso si può dire delle funzioni. Ciò significa che a parità di tutte le altre cose, si finisce con:

  • Più classi / tipi
  • Metodi più brevi

Ora, se si desidera utilizzare la notazione ungherese, è necessario decidere se applicarla su tutta la linea o semplicemente utilizzarla per determinati tipi e classi privilegiati (come le classi della libreria principale). Quest'ultima non ha senso per me, e la prima porta al "labirinto di cercare di trovare abbreviazioni diverse in mille tipi diversi" a cui si riferiva Péter Török. Ciò significa che esiste un notevole sovraccarico nel mantenimento degli elenchi delle abbreviazioni e di solito "denominazione variabile costante" esce dalla finestra.

Il secondo punto sui metodi più brevi significa che nella maggior parte dei casi, non sarà necessario passare attraverso centinaia di righe di codice per verificare il tipo di variabile. Naming un po 'più attentamente le variabili eliminerebbe alcune delle vostre altre domande - ad esempio, cityNamecontro solo city. Spero che cityNamenon sia un galleggiante :)

Per quanto riguarda il motivo per cui infastidisce le persone, di nuovo, questo probabilmente dipende dall'essere abituato o no. Ma come qualcuno che non ci è abituato, posso dirti che l'uso della notazione ungherese interrompe il flusso di codice per i miei occhi, rendendo più difficile la lettura rapida. Per riassumere, non sto dicendo che non ha alcun merito (anche se non ho discusso alcuni dei suoi svantaggi, in termini di refactoring, ecc.), Sto dicendo che lo sforzo non è utile, per linguaggi OO fortemente tipizzati.


1

Non lo so nel contesto di C ++ ma nel mondo Java / C # preferirei di gran lunga avere nomi significativi che trasmettono un linguaggio di dominio o un contesto piuttosto che dirmi che strFirstNameè una stringa; dovrebbe essere ovvio che si tratta di una stringa o il nome deve essere riformattato per comunicare un intento migliore. Se hai bisogno di un prefisso per conoscere il tipo di cosa stai lavorando, direi che la tua denominazione è incoerente, non abbastanza descrittiva o decisamente sbagliata. Nelle lingue moderne preferisco sempre nomi più lunghi che non lasciano ambiguità rispetto a nomi vaghi o ambigui.

L'unica volta che uso l'ungherese è per i controlli ASP.NET, e in particolare IA) non è necessario digitare qualcosa di molto lungo come CustomerFirstNameTextBoxcontro txtCustomerFirstName, e B) Quindi Intellisense ordinerà tutti i tipi di controllo. Mi sento "sporco" anche se lo faccio, però, devo ancora trovare un modo migliore.


0

Meh - si tratta davvero di preferenze personali, non importa quanto si cerchi di razionalizzare le proprie scelte. Mi attengo personalmente alla regola "When in Rome ..." e uso l'ungherese nel codice che chiama molto l'API di Windows. Per il codice indipendente dalla piattaforma, tendo a seguire lo stile di libreria standard C ++.


0

La risposta sta in questa domanda: per favore, dimmi come nominare le seguenti variabili:

char * nullTerminatedString;
wchar * nullTerminatedWideString;
string stlString;
wstring stlWideString;
CString mfcString;
BSTR comString;
_bstr_t atlString;

Aggiungi a queste stringhe costanti, puntatore a queste e puntatori costanti a queste.


3
szFoo, wczFoo, strFoo, (w)strFoo, strFoo, bstrFoo,bstrFoo
Coder

0

Non mi piace molto la forma di notazione ungherese che descrivi. La ragione? Non serve il 90% delle volte.

Ad esempio, un po 'di (equivalente C ++. Scritto in Delphi) da un progetto legacy che sono costretto a sopportare:

pRecords[0]->FooMember=10;

... pRecord è una variabile, è di tipo TRecordList. TRecordList *pRecords[10];

È una classe composta da un'origine chiamata FooMember che punta a fFooMember ... o mFooMember a seconda che si tratti di un "campo" o di un "membro" (suggerimento: sono la stessa cosa)

I problemi? fFooMemberpotrebbe essere qualcosa come FooMember_ perché accederemo sempre tramite la proprietà pubblica FooMember. pRecords? È abbastanza ovvio che è un indicatore del fatto che tu lo dereferenzi dappertutto. TRecordList? Quando puoi confondere un nome di tipo e un oggetto di quel tipo? Il compilatore ti urlerà contro e i tipi vengono usati in quasi nessun luogo in cui si trovano gli oggetti (tranne che per proprietà / metodi statici)

Ora, c'è un posto dove uso la notazione ungherese. Questo è quando si ha a che fare con molte variabili dell'interfaccia utente che avrebbero lo stesso nome di altre variabili dell'interfaccia utente o variabili regolari.

Ad esempio, se avessi un modulo per il tuo nome su di esso.

Avrei una classe chiamata FirstNameForm. Al suo interno, lblFirstName e txtFirstName rispettivamente per l'etichetta e la casella di testo. E una proprietà pubblica FirstName per ottenere e impostare il nome nella casella di testo.

Questo potrebbe essere risolto anche usando FirstNameLabel e FirstNameTextBox ma trovo che il tempo di scrivere sia lungo. Soprattutto con qualcosa come GenderDropDownList e simili.

Quindi, in sostanza, la notazione ungherese è, nella migliore delle ipotesi, fastidiosa a livello sistematico e il peggior caso dannoso (poiché le altre risposte danno problemi di refactoring e coerenza).

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.