Perché non dovrei usare la "Notazione ungherese"?

Question

So a cosa si riferisce l'ungherese: fornire informazioni su una variabile, un parametro o un tipo come prefisso al suo nome. Tutti sembrano essere rabbiosamente contrari, anche se in alcuni casi sembra essere una buona idea. Se ritengo che vengano comunicate informazioni utili, perché non dovrei metterle lì dove sono disponibili?

Vedi anche: Le persone usano il Convenzioni di denominazione ungherese nel mondo reale?

Answer 1

Molte persone usano la notazione ungherese in modo sbagliato e ottengono risultati sbagliati.

Leggi questo eccellente articolo di Joel Spolsky: Far sembrare sbagliato il codice sbagliato .

In breve, la notazione ungherese in cui si antepongono i nomi delle variabili con il loro tipo (stringa) (sistemi ungheresi) è male perché è inutile.

Notazione ungherese come intendeva il suo autore in cui si antepone il nome della variabile con il suo tipo (usando l'esempio di Joel: stringa sicura o stringa non sicura), la cosiddetta Apps Hungarian ha i suoi usi ed è ancora prezioso.

Answer 2

vUsing adjHungarian nnotation vmakes nreading nCode adjdifficult.

Answer 3

Joel ha torto, ed ecco perché.

Quella " applicazione " le informazioni di cui sta parlando dovrebbero essere codificate nel sistema di tipi . Non dovresti dipendere dal lancio di nomi di variabili per assicurarti di non trasmettere dati non sicuri a funzioni che richiedono dati sicuri. Dovresti renderlo un errore di tipo, quindi è impossibile farlo. Tutti i dati non sicuri devono avere un tipo contrassegnato come non sicuro, in modo che semplicemente non possa essere passato a una funzione sicura. Per convertire da non sicuro a sicuro dovrebbe richiedere l'elaborazione con una sorta di funzione sanitize.

Molte delle cose di cui Joel parla come "tipi" non sono tipi; sono, infatti, tipi.

Ciò che manca alla maggior parte delle lingue, tuttavia, è un sistema di tipi sufficientemente espressivo da applicare questo tipo di distinzioni. Ad esempio, se C avesse una sorta di "typedef forte". (dove il nome typedef aveva tutte le operazioni del tipo base, ma non era convertibile in esso) molti di questi problemi sarebbero scomparsi. Ad esempio, se potessi dire, strong typedef std :: string unsafe_string; per introdurre un nuovo tipo unsafe_string che non può essere convertito in std :: string (e così via potrebbe partecipare alla risoluzione del sovraccarico, ecc. ecc.), quindi non avremmo bisogno di stupidi prefissi.

Quindi, l'affermazione centrale secondo cui l'ungherese è per cose che non sono tipi è sbagliata. Viene utilizzato per informazioni sul tipo. Informazioni di tipo più ricco rispetto alle informazioni di tipo C tradizionale, certamente; sono le informazioni di tipo che codificano una sorta di dettaglio semantico per indicare lo scopo degli oggetti. Ma sono ancora informazioni sul tipo e la soluzione corretta è sempre stata quella di codificarle nel sistema dei tipi. La codifica nel sistema dei tipi è di gran lunga il modo migliore per ottenere la corretta convalida e applicazione delle regole. I nomi delle variabili semplicemente non tagliano la senape.

In altre parole, l'obiettivo non dovrebbe essere "far apparire errato il codice allo sviluppatore". Dovrebbe essere " fare apparire il codice sbagliato nel compilatore " ;.

Answer 4

Penso che ingombra enormemente il codice sorgente.

Inoltre non ti guadagna molto in un linguaggio fortemente tipizzato. Se esegui qualsiasi forma di tipo non corrispondente tomfoolery, il compilatore te lo dirà.

Answer 5

La notazione ungherese ha senso solo nelle lingue senza tipi definiti dall'utente . In un moderno linguaggio funzionale o OO, codificheresti informazioni sul tipo di "tipo" di valore nel tipo di dati o nella classe anziché nel nome della variabile.

Diverse risposte fanno riferimento a Articolo Joels . Si noti tuttavia che il suo esempio è in VBScript, che non supportava le classi definite dall'utente (almeno per molto tempo). In una lingua con tipi definiti dall'utente, risolverebbe lo stesso problema creando un tipo HtmlEncodedString e quindi consentire al metodo Write di accettare solo quello. In un linguaggio tipizzato staticamente, il compilatore rileverà eventuali errori di codifica, in un tipo dinamico si otterrà un'eccezione di runtime - ma in ogni caso si è protetti dalla scrittura di stringhe non codificate. Le notazioni ungheresi trasformano il programmatore in un controllo di tipo umano, con il tipo di lavoro che in genere è meglio gestito dal software.

Joel distingue tra "sistemi ungheresi" e "app ungherese", dove "ungherese sistemi" codifica i tipi predefiniti come int, float e così via e " app hungarian " codifica "tipi", che è una meta-informazione di livello superiore sulla variabile oltre il tipo di macchina, in un OO o in un linguaggio funzionale moderno puoi creare tipi definiti dall'utente, quindi non c'è distinzione tra tipo e "tipo" in questo senso - entrambi possono essere rappresentati dal sistema di tipi - e " app " l'ungherese è ridondante tanto quanto i "sistemi" ungherese.

Quindi, per rispondere alla tua domanda: Sistemi ungheresi sarebbe utile solo in un linguaggio non sicuro, tipicamente debolmente dove ad es. l'assegnazione di un valore float a una variabile int provoca l'arresto anomalo del sistema. La notazione ungherese è stata appositamente inventata negli anni sessanta per essere utilizzata in BCPL , un linguaggio di basso livello che non ha non fare alcun tipo di controllo. Oggi non credo che nessuna lingua di uso generale abbia questo problema, ma la notazione è sopravvissuta come una sorta di programmazione di culto del carico .

App ungherese avrà senso se stai lavorando con un linguaggio senza tipi definiti dall'utente, come VBScript legacy o versioni precedenti di VB. Forse anche le prime versioni di Perl e PHP. Ancora una volta, usarlo in un linguaggio moderno è puro culto del carico.

In qualsiasi altra lingua, l'ungherese è semplicemente brutto, ridondante e fragile. Ripete le informazioni già note dal sistema dei tipi e non dovresti ripetere . Utilizzare un nome descrittivo per la variabile che descrive l'intento di questa specifica istanza del tipo. Utilizza il sistema dei tipi per codificare invarianti e meta-informazioni su " generi " o "classi" di variabili - ad es. tipi.

Il punto generale dell'articolo di Joels - avere un codice sbagliato sembra sbagliato - è un ottimo principio. Tuttavia, una protezione ancora migliore contro i bug è, quando possibile, avere codice errato per essere rilevato automaticamente dal compilatore.

Answer 6

Uso sempre la notazione ungherese per tutti i miei progetti. Lo trovo davvero utile quando ho a che fare con centinaia di nomi di identificatori diversi.

Ad esempio, quando chiamo una funzione che richiede una stringa, posso digitare 's' e premere control-space e il mio IDE mi mostrerà esattamente i nomi delle variabili con il prefisso 's'.

Un altro vantaggio, quando ho il prefisso u per unsigned e i per ints firmati, vedo immediatamente dove sto mescolando sign e unsigned in modi potenzialmente pericolosi.

Non ricordo il numero di volte in cui in un enorme codebase di 75000 righe, i bug sono stati causati (anche da me e da altri) a causa della denominazione delle variabili locali allo stesso modo delle variabili membro esistenti di quella classe. Da allora, ho sempre prefisso i membri con 'm_'

È una questione di gusto ed esperienza. Non bussare fino a quando non l'hai provato.

Answer 7

Stai dimenticando il motivo numero uno per includere queste informazioni. Non ha niente a che fare con te, il programmatore. Ha tutto a che fare con la persona che viene giù per la strada 2 o 3 anni dopo aver lasciato la compagnia che deve leggere quella roba.

Sì, un IDE identificherà rapidamente i tipi per te. Tuttavia, quando stai leggendo alcuni lunghi lotti di codice "regole aziendali", è bello non dover fare una pausa su ciascuna variabile per scoprire di che tipo è. Quando vedo cose come strUserID, intProduct o guiProductID, rende molto più facile il tempo di "accelerazione".

Sono d'accordo sul fatto che MS abbia esagerato con alcune delle loro convenzioni di denominazione - lo categorizzo nella sezione "troppo buona" mucchio.

Le convenzioni di denominazione sono buone cose, a patto che ti atterri a esse. Ho esaminato abbastanza vecchio codice che mi ha fatto tornare costantemente a guardare le definizioni di così tante variabili con nomi simili che spingo "camel casing" (come era stato chiamato in un precedente lavoro). In questo momento sono in un lavoro che ha molte migliaia di righe di codice ASP classico completamente non commentato con VBScript ed è un incubo che cerca di capire le cose.

Answer 8

Il superamento di caratteri criptici all'inizio di ogni nome di variabile non è necessario e mostra che il nome della variabile da solo non è abbastanza descrittivo. La maggior parte delle lingue richiede comunque il tipo di variabile alla dichiarazione, quindi le informazioni sono già disponibili.

C'è anche la situazione in cui, durante la manutenzione, un tipo variabile deve cambiare. Esempio: se una variabile dichiarata come " uint_16 u16foo " deve diventare un unsigned a 64 bit, accadrà una delle due cose:

1. Passerai attraverso e cambierai il nome di ogni variabile (assicurandoti di non inserire nessuna variabile non correlata con lo stesso nome), oppure
2. Basta cambiare il tipo e non cambiare il nome, il che causerà solo confusione.

Answer 9

Joel Spolsky ha scritto un buon post sul blog a riguardo. http://www.joelonsoftware.com/articles/Wrong.html Fondamentalmente si riduce a non rendere più difficile la lettura del codice quando un IDE decente ti dirà che vuoi digitare la variabile se non ricordi. Inoltre, se rendi il tuo codice abbastanza compartimentato, non devi ricordare quale variabile è stata dichiarata come tre pagine in su.

Answer 10

L'ambito non è più importante del tipo in questi giorni, ad esempio

* l for local
* a for argument
* m for member
* g for global
* etc

Con le moderne tecniche di refactoring del vecchio codice, la ricerca e la sostituzione di un simbolo perché il suo tipo è cambiato è noioso, il compilatore rileverà le modifiche al tipo, ma spesso non rileva un uso errato dell'ambito, le convenzioni di denominazione sensate aiutano qui.

Answer 11

Non vi è alcun motivo per cui non si dovrebbe usare corretto l'uso della notazione ungherese. La sua impopolarità è dovuta a una lunga serie di contraccolpi contro il uso improprio della notazione ungherese, specialmente nelle API di Windows.

Ai vecchi tempi, prima che esistesse qualcosa di simile a un IDE per DOS (è probabile che tu non avessi abbastanza memoria libera per eseguire il compilatore sotto Windows, quindi il tuo sviluppo è stato fatto in DOS), non hai ottenuto qualsiasi aiuto da passare il mouse sopra un nome di variabile. (Supponendo che tu avessi un mouse.) Che cosa avevi a che fare erano le funzioni di callback di eventi in cui tutto ti veniva passato come int a 16 bit (WORD) o int a 32 bit (LONG WORD). È stato quindi necessario castare tali parametri nei tipi appropriati per il tipo di evento specificato. In effetti, gran parte dell'API era praticamente senza tipo.

Il risultato, un'API con nomi di parametri come questi:

LRESULT CALLBACK WindowProc(HWND hwnd,
                            UINT uMsg,
                            WPARAM wParam,
                            LPARAM lParam);

Nota che i nomi wParam e lParam, sebbene piuttosto terribili, non sono in realtà peggiori del nominarli param1 e param2.

A peggiorare le cose, Windows 3.0 / 3.1 aveva due tipi di puntatori, vicino e lontano. Quindi, ad esempio, il valore restituito dalla funzione di gestione della memoria LocalLock era un PVOID, ma il valore restituito da GlobalLock era un LPVOID (con la "L" per un lungo periodo). Quella terribile notazione è stata quindi estesa in modo che una stringa ointer l ong ?? p fosse preceduta da lp , per distinguerla da una stringa che era stata semplicemente malloc 'd.

Non sorprende che ci sia stata una reazione contraria a questo genere di cose.

Answer 12

La notazione ungherese può essere utile nelle lingue senza la verifica del tipo in fase di compilazione, poiché consentirebbe allo sviluppatore di ricordare rapidamente a se stessa come viene utilizzata la particolare variabile. Non fa nulla per prestazioni o comportamento. Dovrebbe migliorare la leggibilità del codice ed è principalmente una questione di gusto e stile di codifica. Proprio per questo è criticato da molti sviluppatori, non tutti hanno lo stesso cablaggio nel cervello.

Per le lingue di verifica del tipo in fase di compilazione è per lo più inutile: lo scorrimento di alcune righe dovrebbe rivelare la dichiarazione e quindi digitare. Se le variabili globali o il blocco di codice si estendono per più di una schermata, si hanno gravi problemi di progettazione e riusabilità. Pertanto, una delle critiche è che la Notazione ungherese consente agli sviluppatori di progettare male e di cavarsela facilmente. Questo è probabilmente uno dei motivi per odiare.

D'altra parte, ci possono essere casi in cui anche le lingue di verifica del tipo in fase di compilazione trarrebbero beneficio dalla notazione ungherese - void puntatori o HANDLE in win32 API. Ciò offusca il tipo di dati effettivo e potrebbe esserci il merito di utilizzare la notazione ungherese lì. Tuttavia, se uno può conoscere il tipo di dati al momento della creazione, perché non utilizzare il tipo di dati appropriato.

In generale, non ci sono motivi concreti per non usare la notazione ungherese. È una questione di Mi piace, politiche e stile di codifica.

Answer 13

Come programmatore di Python, la Notazione ungherese cade piuttosto velocemente. In Python, non mi interessa se qualcosa è una stringa - mi importa se può comportarsi come una stringa (cioè se ha un ___ str ___ () metodo che restituisce una stringa).

Ad esempio, supponiamo di avere foo come numero intero, 12

foo = 12

La notazione ungherese ci dice che dovremmo chiamare quell'iFoo o qualcosa del genere, per indicare che è un numero intero, così che in seguito, sappiamo di cosa si tratta. Tranne che in Python, ciò non funziona, o meglio, non ha senso. In Python, decido quale tipo voglio quando lo uso. Voglio una stringa? bene se faccio qualcosa del genere:

print "The current value of foo is %s" % foo

Nota la stringa % s . Foo non è una stringa, ma l'operatore % chiamerà foo .___ str ___ () e utilizzerà il risultato (supponendo che esista). foo è ancora un numero intero, ma lo trattiamo come una stringa se vogliamo una stringa. Se vogliamo un galleggiante, lo trattiamo come un galleggiante. In linguaggi tipicamente dinamici come Python, la notazione ungherese è inutile, perché non importa quale tipo sia qualcosa fino a quando non lo usi e se hai bisogno di un tipo specifico, assicurati di lanciarlo su quel tipo (ad esempio float (pippo) ) quando lo usi.

Nota che i linguaggi dinamici come PHP non hanno questo vantaggio - PHP cerca di fare "la cosa giusta" in background sulla base di un oscuro insieme di regole che quasi nessuno ha memorizzato, il che si traduce spesso in disastri catastrofici inaspettatamente. In questo caso, può essere utile una sorta di meccanismo di denominazione, come $ files_count o $ file_name .

A mio avviso, la notazione ungherese è come le sanguisughe. Forse in passato erano utili, o almeno sembravano utili, ma al giorno d'oggi è solo un sacco di digitazione extra per non molti benefici.

Answer 14

L'IDE dovrebbe fornire tali informazioni utili. L'ungherese avrebbe potuto avere un qualche senso (non molto, ma una sorta) di senso quando gli IDE erano molto meno avanzati.

Answer 15

Le app ungherese sono greche per me - in senso buono

Come ingegnere, non come programmatore, ho immediatamente seguito l'articolo di Joel sul merito di Apps Hungarian: " Far sembrare sbagliato il codice sbagliato " . Mi piacciono le app ungheresi perché imita il modo in cui ingegneria, scienza e matematica rappresentano equazioni e formule che utilizzano simboli sub e super-script (come lettere greche, operatori matematici, ecc.). Prendi un esempio particolare di Newton's Law of Universal Gravity : prima nella notazione matematica standard, e quindi nello pseudo-codice ungherese di Apps:

frcGravityEarthMars = G * massEarth * massMars / norm(posEarth - posMars)

Nella notazione matematica, i simboli più importanti sono quelli che rappresentano il tipo delle informazioni memorizzate nella variabile: forza, massa, vettore di posizione, ecc. Gli abbonati giocano il secondo violino per chiarire: posizione di che cosa? Questo è esattamente ciò che sta facendo Apps Hungarian; ti sta dicendo il tipo delle cose memorizzate nella variabile prima e poi entrando nei dettagli - il codice più vicino può arrivare alla notazione matematica.

La tipizzazione chiaramente forte può risolvere l'esempio di stringa sicura o non sicura dal saggio di Joel, ma non definiresti tipi separati per i vettori di posizione e velocità; entrambi sono matrici doppie di dimensione tre e tutto ciò che è probabile che facciate all'una potrebbe applicarsi all'altra. Inoltre, ha perfettamente senso concatenare posizione e velocità (per creare un vettore di stato) o prendere il loro prodotto punto, ma probabilmente non aggiungerli. In che modo la digitazione consentirebbe i primi due e proibirebbe il secondo, e in che modo un tale sistema si estenderebbe a ogni possibile operazione che potresti voler proteggere? A meno che tu non sia disposto a codificare tutta la matematica e la fisica nel tuo sistema di battitura.

Inoltre, molta ingegneria viene fatta in linguaggi di alto livello tipicamente deboli come Matlab, o vecchi come Fortran 77 o Ada.

Quindi, se hai un linguaggio fantasioso e IDE e App l'ungherese non ti aiuta, allora dimenticalo - a quanto pare un sacco di gente. Ma per me, peggiore di un programmatore alle prime armi che lavora in linguaggi debolmente o dinamicamente digitati, posso scrivere un codice migliore più velocemente con Apps Hungarian che senza.

Answer 16

È incredibilmente ridondante e inutile è la maggior parte degli IDE moderni, in cui fanno un buon lavoro nel rendere evidente il tipo.

Inoltre - per me - è solo fastidioso vedere intI, strUserName, ecc. :)

Answer 17

  

Se ritengo che vengano comunicate informazioni utili, perché non dovrei metterle lì dove sono disponibili?

Allora a chi importa cosa pensa qualcun altro? Se lo trovi utile, utilizza la notazione.

Answer 18

Sono la mia esperienza, è un male perché:

1 - quindi si interrompe tutto il codice se è necessario modificare il tipo di una variabile (ovvero se è necessario estendere un numero intero a 32 bit a un numero intero a 64 bit);

2: si tratta di informazioni inutili in quanto il tipo è già nella dichiarazione o si utilizza un linguaggio dinamico in cui il tipo effettivo non dovrebbe essere così importante in primo luogo.

Inoltre, con un linguaggio che accetta la programmazione generica (ovvero funzioni in cui il tipo di alcune variabili non viene determinato quando si scrive la funzione) o con un sistema di digitazione dinamico (ovvero quando il tipo non viene nemmeno determinato al momento della compilazione), come dai un nome alle tue variabili? E la maggior parte delle lingue moderne supporta l'una o l'altra, anche se in forma limitata.

Answer 19

In Il codice errato di Joel Spolsky sembra sbagliato spiega che ciò che tutti pensano poiché la notazione ungherese (che chiama sistemi ungheresi) non è ciò che doveva essere realmente (ciò che chiama app ungherese). Scorri verso il basso fino alla I & # 8217; m Ungheria per vedere questa discussione.

Fondamentalmente, i sistemi ungheresi sono privi di valore. Ti dice solo la stessa cosa che ti diranno il tuo compilatore e / o IDE.

App Ungherese ti dice cosa dovrebbe significare la variabile e può effettivamente essere utile.

Answer 20

Ho sempre pensato che un prefisso o due nel posto giusto non avrebbero fatto male. Penso che se posso impartire qualcosa di utile, come " Ehi, questa è un'interfaccia, non contare su un comportamento specifico " proprio lì, come in IEnumerable, dovrei farlo. Il commento può ingombrare molto di più di un semplice simbolo di uno o due caratteri.

Answer 21

È una convenzione utile per nominare i controlli in un modulo (btnOK, txtLastName ecc.), se l'elenco dei controlli viene visualizzato in un elenco a discesa alfabetico nell'IDE.

Answer 22

Tendo a usare la notazione ungherese con i controlli del server ASP.NET solo , altrimenti trovo troppo difficile capire quali controlli sono cosa nel modulo.

Prendi questo frammento di codice:

<asp:Label ID="lblFirstName" runat="server" Text="First Name" />
<asp:TextBox ID="txtFirstName" runat="server" />
<asp:RequiredFieldValidator ID="rfvFirstName" runat="server" ... />

Se qualcuno può mostrare un modo migliore di avere quel set di nomi di controllo senza ungherese, sarei tentato di passare ad esso.

Answer 23

L'articolo di Joel è eccezionale, ma sembra omettere un punto importante:

L'ungherese rende unica una 'idea' (tipo + nome identificativo), o quasi univoco, attraverso la base di codice - anche una base di codice molto grande.

È eccezionale per la manutenzione del codice. Significa che puoi usare una buona ricerca di testo a riga singola (grep, findstr, "trova in tutti i file") per trovare OGNI menzione di tale "idea".

Perché è importante quando abbiamo IDE che sanno leggere il codice? Perché non sono ancora molto bravi. Questo è difficile da vedere in una piccola base di codice, ma ovvio in grande - quando l'idea potrebbe essere menzionata nei commenti, File XML, script Perl e anche in luoghi al di fuori del controllo del codice sorgente (documenti, wiki, database di bug).

Devi stare un po 'attento anche qui, ad es. incollare token nelle macro C / C ++ può nascondere menzioni dell'identificatore. Tali casi possono essere trattati con l'utilizzo convenzioni di codifica e comunque tendono a colpire solo una minoranza degli identificatori nel file codebase.

P.S. Al punto di usare il sistema dei tipi contro l'ungherese, è meglio usare entrambi. Hai solo bisogno di un codice sbagliato per apparire sbagliato se il compilatore non lo rileva per te. Ci sono molti casi in cui è impossibile far catturare il compilatore. Ma dove è fattibile - sì, per favore fallo invece!

Quando si considera la fattibilità, tuttavia, considerare gli effetti negativi della suddivisione dei tipi. per esempio. in C #, il wrapping di "int" con un tipo non incorporato ha conseguenze enormi. Quindi ha senso in alcune situazioni, ma non in tutte.

Answer 24

Debunking i vantaggi della notazione ungherese

• Fornisce un modo per distinguere le variabili.

Se il tipo è tutto ciò che distingue un valore da un altro, allora può essere solo per la conversione di un tipo in un altro. Se hai lo stesso valore che viene convertito tra tipi, è probabile che dovresti farlo in una funzione dedicata alla conversione. (Ho visto gli avanzi di VB6 ungheresi utilizzare le stringhe su tutti i loro parametri del metodo semplicemente perché non sono stati in grado di capire come deserializzare un oggetto JSON o comprendere correttamente come dichiarare o utilizzare tipi nullable. ) Se si hanno due variabili distinte solo dal prefisso ungherese e non sono una conversione dall'una all'altra, quindi devi elaborare la tua intenzione con loro.

• Rende il codice più leggibile.

Ho scoperto che la notazione ungherese rende le persone pigre con i loro nomi variabili. Hanno qualcosa per distinguerlo e non sentono il bisogno di elaborare il suo scopo. Questo è quello che troverai tipicamente nel codice ungherese rispetto al moderno: sSQL vs. groupSelectSql ( o di solito nessun sSQL perché si suppone che stiano usando l'ORM che era stato introdotto dagli sviluppatori precedenti. ), sValue vs. formCollectionValue ( o in genere neanche sValue, perché si trovano in MVC e dovrebbero usare le sue funzionalità di associazione del modello ), sType vs. publishingSource, ecc.

Non può essere leggibile. Vedo più sTemp1, sTemp2 ... sTempN da qualsiasi dato VB6 ungherese rimasto di tutti gli altri messi insieme.

• Previene errori.

Questo sarebbe in virtù del numero 2, che è falso.

Answer 25

Nelle parole del maestro:

http://www.joelonsoftware.com/articles/Wrong.html

Una lettura interessante, come al solito.

Gli estratti:

"Qualcuno, da qualche parte, ha letto il documento di Simonyi, dove ha usato la parola" tipo ", # 8221; e pensava che intendesse tipo, come classe, come in un sistema di tipi, come il tipo che controlla il compilatore. Non l'ha fatto. Ha spiegato con molta attenzione esattamente cosa intendesse con la parola & # 8220; tipo, & # 8221; ma non ha aiutato. Il danno è stato fatto. & Quot;

"Ma c'è ancora un'enorme quantità di valore per Apps Hungarian, in quanto aumenta la collocazione nel codice, il che rende il codice più facile da leggere, scrivere, eseguire il debug e mantenere, e, soprattutto, esso fa apparire sbagliato il codice sbagliato. "

Assicurati di avere del tempo prima di leggere Joel On Software. :)

Answer 26

Diversi motivi:

• Qualsiasi IDE moderno ti darà il tipo di variabile semplicemente passando il mouse sulla variabile.
• La maggior parte dei nomi dei tipi sono molto lunghi (pensa HttpClientRequestProvider ) per essere ragionevolmente usati come prefisso.
• Le informazioni sul tipo non contengono le informazioni giuste , stanno solo parafrasando la dichiarazione della variabile, invece di delineare lo scopo della variabile (pensa myInteger vs. pageSize ).

Answer 27

Non penso che tutti siano rabbiosamente contrari. In lingue senza tipi statici, è piuttosto utile. Lo preferisco sicuramente quando viene utilizzato per fornire informazioni che non sono già nel tipo. Come in C, char * szName afferma che la variabile farà riferimento a una stringa con terminazione null - che non è implicita in char * - ovviamente, sarebbe utile anche un typedef.

Joel ha pubblicato un ottimo articolo sull'uso dell'ungherese per dire se una variabile era codificata in HTML o meno:

http://www.joelonsoftware.com/articles/Wrong.html

In ogni caso, tendo a non apprezzare l'ungherese quando viene utilizzato per impartire informazioni che già conosco.

Answer 28

Naturalmente quando il 99% dei programmatori concorda su qualcosa, c'è qualcosa che non va. Il motivo per cui sono d'accordo qui è perché la maggior parte di loro non ha mai usato correttamente la notazione ungherese.

Per un argomento dettagliato, vi rimando a un post sul blog che ho scritto sull'argomento.

http://codingthriller.blogspot.com/2007/11 /rediscovering-hungarian-notation.html

Answer 29

Ho iniziato a scrivere codice praticamente all'epoca in cui è stata inventata la notazione ungherese e la prima volta che sono stato costretto a usarlo su un progetto l'ho odiato.

Dopo un po 'mi sono reso conto che quando è stato fatto correttamente mi ha davvero aiutato e in questi giorni lo adoro.

Ma come tutte le cose buone, deve essere appreso e compreso e per farlo correttamente richiede tempo.

Answer 30

La notazione ungherese è stata abusata, in particolare da Microsoft, portando a prefissi più lunghi del nome della variabile e mostrandola piuttosto rigida, in particolare quando si cambiano i tipi (il famigerato lparam / wparam, di diverso tipo / dimensione in Win16, identico in Win32).

Quindi, sia a causa di questo abuso, sia per il suo utilizzo da parte di M $, è stato considerato inutile.

Nel mio lavoro, programmiamo in Java, ma il fondatore viene dal mondo MFC, quindi usa uno stile di codice simile (parentesi graffe allineate, mi piace !, maiuscole per i nomi dei metodi, mi sono abituato, prefisso come m_ alla classe membri (campi), da s_ a membri statici, ecc.).

E hanno detto che tutte le variabili dovrebbero avere un prefisso che mostra il suo tipo (es. un BufferedReader si chiama brData). Che si è rivelato essere una cattiva idea, poiché i tipi possono cambiare ma i nomi non seguono o i programmatori non sono coerenti nell'uso di questi prefissi (vedo anche aBuffer, theProxy, ecc.!).

Personalmente, ho scelto per alcuni prefissi che trovo utili, la più importante è la b per prefissare le variabili booleane, in quanto sono le uniche in cui consento la sintassi come if (bVar) (no uso dell'autocast di alcuni valori su true o false). Quando ho codificato in C, ho usato un prefisso per le variabili allocate con malloc, come promemoria che dovrebbe essere liberato in seguito. Ecc.

Quindi, fondamentalmente, non rifiuto questa notazione nel suo insieme, ma ho preso ciò che sembra appropriato per i miei bisogni.
E, naturalmente, quando contribuisco ad alcuni progetti (lavoro, open source), utilizzo semplicemente le convenzioni in atto!