Qual è il vantaggio di non usare la notazione ungherese?

Una delle cose con cui faccio fatica non è usare la notazione ungherese. Io non voglio avere per andare alla definizione della variabile solo per vedere che tipo è. Quando un progetto diventa esteso, è bello poter guardare una variabile con il prefisso 'bool' e sapere che sta cercando vero / falso invece di un valore 0/1 .

Faccio anche molto lavoro in SQL Server. Prefisso le mie stored procedure con 'sp' e le mie tabelle con 'tbl', per non parlare rispettivamente di tutte le mie variabili nel database.

Vedo ovunque che nessuno vuole davvero usare la notazione ungherese, al punto da evitarlo. La mia domanda è: qual è il vantaggio di non usare la notazione ungherese, e perché la maggior parte degli sviluppatori la evita come la peste?

Perché la sua intenzione originale (vedi http://www.joelonsoftware.com/articles/Wrong.html e http://fplanque.net/Blog/devblog/2005/05/11/hungarian_notation_on_steroids ) è stata fraintesa ed è stata ( ab) usato per aiutare le persone a ricordare che tipo è una variabile quando la lingua che usano non è tipizzata staticamente. In qualsiasi linguaggio tipicamente statico non è necessario il reattore di prefissi aggiunto per dirti di che tipo è una variabile. In molti linguaggi di script non tipizzati può aiutare, ma è stato spesso abusato al punto da diventare totalmente ingombrante. Sfortunatamente, invece di tornare all'intento originale della notazione ungherese, la gente è appena diventata una di quelle cose "malvagie" che dovresti evitare.

In breve, la notazione ungherese era intesa come prefisso per le variabili con una semantica. Ad esempio, se si hanno coordinate dello schermo (sinistra, in alto, a destra, in basso), si antepongono le variabili con posizioni assolute dello schermo con " abs" e variabili con posizioni relative a una finestra con " rel". In questo modo sarebbe ovvio per qualsiasi lettore quando si passava una coordinata relativa a un metodo che richiede posizioni assolute.

aggiornamento (in risposta al commento di delnan)

IMHO la versione maltrattata dovrebbe essere evitata come la peste perché:

• complica la denominazione. Quando (ab) si utilizza la notazione ungherese, si terranno sempre discussioni su come devono essere specifici i prefissi. Ad esempio: listboxXYZo MyParticularFlavourListBoxXYZ.
• allunga i nomi delle variabili senza aiutare a capire a cosa serve la variabile.
• in qualche modo sconfigge l'oggetto dell'esercizio quando per evitare lunghi prefissi questi vengono abbreviati in abbreviazioni e hai bisogno di un dizionario per sapere cosa significa ogni abbreviazione. È un uinumero intero senza segno? un'interfaccia contata senza riferimento? qualcosa a che fare con le interfacce utente? E quelle cose possono durare a lungo . Ho visto prefissi di più di 15 personaggi apparentemente casuali che dovrebbero trasmettere il tipo esatto di var ma in realtà solo mistificare.
• diventa obsoleto velocemente. Quando cambi il tipo di una variabile, le persone invariabilmente (lol) dimenticano di aggiornare il prefisso per riflettere la modifica, o deliberatamente non aggiornarlo perché ciò causerebbe cambiamenti di codice ovunque venga usato il var ...
• complica il parlare di codice perché come "@g". ha detto: I nomi delle variabili con notazione ungherese sono in genere zuppa di alfabeto difficile da pronunciare. Questo inibisce la leggibilità e la discussione del codice, perché non puoi "dire" nessuno dei nomi.
• ... molto di più che non ricordo al momento. Forse perché ho avuto il piacere di non avere a che fare con l'abuso notazione ungherese da molto tempo ...

La notazione ungherese è un anti-modello di denominazione negli ambienti di programmazione odierni e nella forma di Tautologia .

Ripete inutilmente le informazioni senza alcun vantaggio e costi di manutenzione aggiuntivi. Cosa succede quando cambi il tuo intin un tipo diverso come long, ora devi cercare e sostituire l'intera base di codice per rinominare tutte le variabili o ora sono semanticamente sbagliate, il che è peggio che se non avessi duplicato il tipo nel nome.

Viola il principio DRY. Se devi aggiungere un prefisso alle tue tabelle del database con un'abbreviazione per ricordarti che si tratta di una tabella, allora sicuramente non nominerai le tue tabelle in modo semanticamente descrittivo. Lo stesso vale per ogni altra cosa con cui stai facendo questo. È solo una digitazione extra e funziona senza alcun vantaggio o beneficio in un moderno ambiente di sviluppo.

Wikipedia ha un elenco di vantaggi e svantaggi della notazione ungherese e può quindi probabilmente fornire la risposta più completa a questa domanda. Le notevoli opinioni sono anche una lettura piuttosto interessante.

Il vantaggio di non usare la notazione ungherese è fondamentalmente solo l'evitamento dei suoi svantaggi:

• La notazione ungherese è ridondante quando il compilatore esegue il controllo del tipo. I compilatori per le lingue che forniscono il controllo del tipo assicurano che l'uso di una variabile sia automaticamente coerente con il suo tipo; i controlli ad occhio sono ridondanti e soggetti a errori umani.

• Tutti i moderni ambienti di sviluppo integrato visualizzano tipi variabili su richiesta e contrassegnano automaticamente le operazioni che utilizzano tipi incompatibili, rendendo la notazione ampiamente obsoleta.

• La notazione ungherese diventa confusa quando viene utilizzata per rappresentare diverse proprietà, come in a_crszkvc30LastNameCol: un argomento di riferimento costante, che contiene il contenuto di una colonna LastNamedel database di tipo varchar(30)che fa parte della chiave primaria della tabella.

• Può causare incoerenza quando il codice viene modificato o portato. Se il tipo di una variabile viene modificato, la decorazione sul nome della variabile sarà incoerente con il nuovo tipo o il nome della variabile deve essere modificato. Un esempio particolarmente noto è il WPARAMtipo standard e il wParamparametro formale di accompagnamento in molte dichiarazioni di funzioni del sistema Windows. La "w" sta per "parola", dove "parola" è la dimensione della parola nativa dell'architettura hardware della piattaforma. Originariamente era un tipo a 16 bit su architetture di parole a 16 bit, ma è stato cambiato in un 32 bit su architetture di parole a 32 bit, o un tipo a 64 bit su architetture di parole a 64 bit nelle versioni successive del sistema operativo mantenendo nome originale (il suo vero tipo di base èUINT_PTR, ovvero un numero intero senza segno abbastanza grande da contenere un puntatore). L'impedenza semantica, e quindi la confusione e l'incoerenza del programmatore da una piattaforma all'altra, presuppone che "w" rappresenti 16 bit in questi diversi ambienti.

• Il più delle volte, conoscere l'uso di una variabile implica conoscerne il tipo. Inoltre, se l'uso di una variabile non è noto, non può essere dedotto dal suo tipo.

• La notazione ungherese riduce fortemente i vantaggi dell'utilizzo di editor di codice ricchi di funzionalità che supportano il completamento su nomi di variabili, poiché il programmatore deve inserire prima l'intero identificatore di tipo.

• Rende il codice meno leggibile, offuscando lo scopo della variabile con tipi inutili e prefissi di ambito.

• Le informazioni aggiuntive sul tipo possono sostituire in modo insufficiente nomi più descrittivi. Ad esempio sDatabase, non dice al lettore di cosa si tratta. databaseNamepotrebbe essere un nome più descrittivo.

• Quando i nomi sono sufficientemente descrittivi, le informazioni aggiuntive sul tipo possono essere ridondanti. Ad esempio firstNameè molto probabilmente una stringa. Quindi la denominazione sFirstNameaggiunge solo disordine al codice.

Io stesso non uso questa notazione, perché non mi piace il rumore tecnico non necessario. Quasi sempre so con quale tipo ho a che fare e voglio un linguaggio pulito nel mio modello di dominio, ma scrivo principalmente in linguaggi staticamente e fortemente tipizzati.

Come problema specifico di MS SQL Server:

Qualsiasi procedura memorizzata con il prefisso 'sp_' viene prima cercata nel database Master piuttosto che in quello in cui è stata creata. Ciò provocherà un ritardo nell'esecuzione della procedura memorizzata.

IMO il più grande vantaggio di non usare l'ungherese è il fatto che ti costringe a usare nomi significativi . Se stai nominando le variabili correttamente, dovresti immediatamente sapere di che tipo è o essere in grado di dedurlo abbastanza rapidamente in qualsiasi sistema ben progettato. Se hai bisogno di fare affidamento su stro comunque blnsu tutti i objprefissi per sapere di che tipo è una variabile, direi che indica un problema di denominazione - nomi di variabili scadenti in generale o troppo generici per trasmettere significato.

Ironia della sorte, per esperienza personale lo scenario principale che ho visto l'ungherese usato è la programmazione "cargo-cult" (ovvero viene usato da altro codice, quindi continuiamo ad usarlo solo perché) o in VB.NET per aggirare il fatto che la lingua sia senza distinzione tra maiuscole e minuscole (ad esempio Person oPerson = new Personperché non è possibile utilizzare Person person = new Personed Person p = new Personè troppo vago); Ho anche visto il prefisso "il" o "mio" invece (come in Person thePerson = new Persono il più brutto Person myPerson = new Person), in quel caso particolare.

Aggiungerò l' unica volta che uso l'ungherese tende ad essere per i controlli ASP.NET ed è davvero una questione di scelta. Trovo molto brutto digitare TextBoxCustomerNameo CustomerNameTextBoxcontro il più semplice txtCustomerName, ma anche quello sembra "sporco". Penso che per i controlli debba essere usato un qualche tipo di convenzione di denominazione in quanto possono esserci più controlli che visualizzano gli stessi dati.

Mi concentrerò solo su SQL Server da quando l'hai menzionato. Non vedo alcun motivo per mettere "tbl" davanti a un tavolo. Puoi semplicemente guardare qualsiasi codice tSQL e distinguere una tabella da come viene utilizzata. Non vorresti Select from stored_procedure.o ti piacerebbe mai Select from table(with_param)un UDF o ti Execute tblTableOrViewNamepiacerebbe una procedura memorizzata.

Le tabelle potrebbero essere confuse con una vista, ma quando si tratta di come vengono utilizzate; non c'è differenza, quindi qual è il punto? La notazione ungherese potrebbe farti risparmiare il tempo di cercarla in SSMS (sotto tabella o viste?), Ma questo è tutto.

Le variabili possono presentare un problema, ma devono essere dichiarate e, in realtà, quanto lontano dalla tua dichiarazione dichiari di utilizzare una variabile? Scorrere alcune righe non dovrebbe essere un grosso problema a meno che tu non stia scrivendo procedure molto lunghe. Potrebbe essere una buona idea rompere un po 'il codice lungo.

Quello che descrivi è un dolore, ma la soluzione di notazione ungherese non risolve davvero il problema. Puoi guardare il codice di qualcun altro e scoprire che il tipo di variabile può essere modificato, il che ora richiede una modifica al nome della variabile. Ancora un'altra cosa da dimenticare. E se uso un VarChar, dovrai comunque leggere l'istruzione declare per conoscere la dimensione. I nomi descrittivi ti porteranno probabilmente oltre. @PayPeriodStartDate si spiega praticamente da sé.

Un'altra cosa da aggiungere è che, quali abbreviazioni useresti per un intero framework come .NET? Sì, è così semplice da ricordare che btnrappresenta un pulsante e txtrappresenta una casella di testo. Tuttavia, cosa hai in mente per qualcosa del genere StringBuilder? strbld? Che dire CompositeWebControl? Usi qualcosa del genere:

CompositeWebControl comWCMyControl = new CompositeWebControl();

Una delle inefficienze della notazione ungherese era che, avendo quadri sempre più grandi, non solo dimostrava di non aggiungere ulteriori vantaggi, ma anche di aggiungere maggiore complessità agli sviluppatori, perché ora dovevano imparare sempre di più i prefissi non standard.

Per il mio modo di vedere le cose, la Notazione ungherese è un modo per aggirare un sistema di tipi insufficientemente potente. Nelle lingue che ti consentono di definire i tuoi tipi è relativamente banale creare un nuovo tipo che codifichi il comportamento che ti aspetti. Nell'affermazione di Joel Spolsky sulla Notazione ungherese, egli fornisce un esempio dell'uso per rilevare possibili attacchi XSS indicando che una variabile o una funzione non è sicura (noi) o sicura (e), ma che si basa ancora sul programmatore per controllare visivamente. Se invece disponi di un sistema di tipi estensibile, puoi semplicemente creare due nuovi tipi, UnsafeString e SafeString, quindi utilizzarli come appropriato. Come bonus, il tipo di codifica diventa:

SafeString encode(UnsafeString)

e a corto di accedere agli interni di UnsafeString o utilizzare alcune altre funzioni di conversione diventa l'unico modo per passare da UnsafeString a SafeString. Se tutte le funzioni di output accettano solo istanze di SafeString, diventa impossibile generare una stringa senza escape [escludendo shenanigans con conversioni come StringToSafeString (someUnsafeString.ToString ())].

Dovrebbe essere ovvio il motivo per cui consentire al sistema di tipi di sanità mentale di verificare il codice è superiore a provare a farlo manualmente, o forse occhio in questo caso.

In un linguaggio come C, ovviamente, sei fregato che un int sia un int è un int, e non c'è molto che puoi fare al riguardo. Puoi sempre giocare con le strutture ma è discutibile che si tratti di un miglioramento o meno.

Per quanto riguarda l'altra interpretazione della Notazione ungherese, IE che prefigura il tipo di variabile, è semplicemente stupido e incoraggia pratiche pigre come nominare variabili uivxwFoo invece di qualcosa di significativo come countOfPeople.

La notazione ungherese è quasi completamente inutile in una lingua tipizzata staticamente. È una funzione IDE di base per mostrare il tipo di una variabile posizionandoci sopra con il mouse o con altri mezzi; inoltre puoi vedere qual è il tipo osservando alcune righe in alto dove è stato dichiarato, se non c'è inferenza di tipo. L'intero punto dell'inferenza del tipo è di non ripetere il rumore del tipo ovunque, quindi la notazione ungherese è di solito vista come una cosa negativa nelle lingue con l'inferenza del tipo.

Nelle lingue tipizzate dinamicamente, a volte può aiutare, ma per me sembra unidiomatico. Hai già rinunciato alle tue funzioni limitandoti a domini / codomain esatti; se tutte le variabili sono denominate con notazione ungherese, allora stai semplicemente riproducendo ciò che un sistema di tipo ti avrebbe dato. Come si esprime una variabile polimorfica che può essere un numero intero o una stringa in notazione ungherese? "IntStringX"? "IntOrStringX"? L'unico posto in cui abbia mai usato la notazione ungherese era nel codice assembly, perché stavo cercando di recuperare quello che avrei ottenuto se avessi un sistema di tipi, ed è stata la prima cosa che abbia mai codificato.

Ad ogni modo, non mi potrebbe importare di meno di ciò che le persone chiamano le loro variabili, il codice sarà probabilmente ancora altrettanto incomprensibile. Gli sviluppatori sprecano troppo tempo in cose come lo stile e i nomi delle variabili e alla fine della giornata ottieni ancora un sacco di librerie con convenzioni completamente diverse nella tua lingua. Sto sviluppando un linguaggio simbolico (cioè: non basato su testo) in cui non ci sono nomi di variabili, solo identificatori univoci e nomi suggeriti per le variabili (ma la maggior parte delle variabili non ha ancora un nome suggerito perché semplicemente non esiste un nome ragionevole per loro); quando si controlla il codice non attendibile, non è possibile dipendere da nomi di variabili.

Come sempre in questo caso, posterò una risposta prima di leggere le risposte degli altri partecipanti. 

Vedo tre "bug" nella tua visione: 

1) Se vuoi conoscere il tipo di una variabile / parametro / attributo / colonna puoi passare il mouse o fare clic su di esso e verrà visualizzato, nella maggior parte dei moderni IDE. Non so quali strumenti stai usando, ma l'ultima volta sono stato costretto a lavorare in un ambiente che non forniva questa funzionalità nel 20 ° secolo, il linguaggio era COBOL, oops no era Fortran e il mio capo non capivo perché me ne andassi. 

2 / I tipi possono cambiare durante il ciclo di sviluppo. Un numero intero a 32 bit può diventare un numero intero a 64 bit ad un certo punto, per buoni motivi che non erano stati rilevati all'inizio del progetto. Quindi, rinominare intX in longX o lasciarlo con un nome che punta al tipo sbagliato è un cattivo karma. 

3) Quello che stai chiedendo è in effetti una ridondanza. La ridondanza non è un modello di progettazione o un'abitudine molto validi. Anche gli umani sono riluttanti a troppa ridondanza. Anche gli umani sono riluttanti a troppa ridondanza. 

Credo che avere un disperato bisogno di ungherese sia un sintomo .
Un sintomo di troppe variabili globali ... o di avere funzioni troppo lunghe per essere mantenibili .

Se la tua definizione variabile non è in vista, di solito, hai problemi.
E se le tue funzioni non seguono una convenzione memorabile , ecco di nuovo un grosso problema.

Questo è ... praticamente il motivo per cui molti posti di lavoro lo esplodono, suppongo.

Ha avuto origine nelle lingue che ne avevano bisogno .
In tempi di variabili globali bonanza . (per mancanza di alternative)
Ci è servito bene.

L'unica reale utilizzo che abbiamo per oggi è Joel Spolsky uno .
Per tenere traccia di alcuni attributi particolari della variabile, come la sua sicurezza .

( es. "La variabile safeFoobarha un semaforo verde da iniettare in una query SQL?
- Come si chiama safe, sì")

Alcune altre risposte hanno parlato delle funzionalità dell'editor che hanno aiutato a vedere il tipo di una variabile mentre ci si passa sopra. A mio avviso, anche quelli sono un po ' problematici per la sanità mentale del codice . Credo che significassero solo per il refactoring , come anche molte altre caratteristiche (come la funzione di piegatura) e non dovrebbero essere usate su un nuovo codice.

Penso che i motivi per non usare la notazione ungherese siano stati ben coperti da altri poster. Sono d'accordo con i loro commenti.

Con i database utilizzo la notazione ungherese per gli oggetti DDL che vengono usati raramente nel codice, ma che altrimenti si scontrerebbero negli spazi dei nomi. Principalmente questo si riduce al prefisso degli indici e ai vincoli nominati con il loro tipo (PK, UK, FK e IN). Utilizzare un metodo coerente per denominare questi oggetti e si dovrebbe essere in grado di eseguire alcune convalide eseguendo una query sui metadati.

il motivo per cui viene evitato è a causa dei sistemi ungheresi che violano DRY (il prefisso è esattamente il tipo che il compilatore e (un buon) IDE possono derivare)

prefissi OTOH ungheresi di app con l' uso della variabile (ovvero scrxMouse è ax ax coordinate sullo schermo che può essere un tipo int, short, long o persino personalizzato (typedefs ti permetterà anche di cambiarlo facilmente))

l'incomprensione dei sistemi è ciò che ha distrutto l'ungherese come una buona pratica

Diciamo che abbiamo un metodo come questo (in C #):

int GetCustomerCount()
{
    // some code
}

Ora nel codice lo chiamiamo così:

var intStuff = GetCustomerCount();
// lots of code that culminates in adding a customer
intStuff++;

L' int non ci dice molto. Il semplice fatto che qualcosa sia un int non ci dice cosa ci sia dentro. Supponiamo ora che lo chiamiamo così:

var customerCount = GetCustomerCount();
// lots of code that culminates in adding a customer
customerCount++;

Ora possiamo vedere qual è lo scopo della variabile. Imporrebbe se sappiamo che è un int?

Lo scopo originale dell'ungherese, tuttavia, era di farti fare qualcosa del genere:

var cCustomers = GetCustomerCount();
// lots of code that culminates in adding a customer
cCustomers++;

Questo va bene finché sai cosa sta per c . Ma dovresti avere una tabella standard di prefissi e tutti dovrebbero conoscerli e ogni nuova gente dovrebbe impararli per capire il tuo codice. Considerando che customerCounto countOfCustomersè abbastanza ovvio a prima vista.

L'ungherese aveva uno scopo in VB prima che Option Strict Onesistesse, perché in VB6 e VB precedente (e in VB .NET con Option Strict Off) VB avrebbe forzato i tipi, quindi potresti farlo:

Dim someText As String = "5"
customerCount = customerCount + someText

Questo è male, ma il compilatore non te lo direbbe. Quindi se avessi usato l'ungherese, almeno avresti qualche indicatore di ciò che stava accadendo:

Dim strSomeText As String = "5"
intCustomerCount = intCustomerCount + strSomeText  // that doesn't look right!

In .NET, con la digitazione statica, questo non è necessario. E l'ungherese veniva usato troppo spesso come sostituto di una buona denominazione. Dimentica l'ungherese e scegli invece dei bei nomi.

Ho trovato molti buoni argomenti contrari, ma uno che non ho visto: ergonomia.

In passato, quando tutto ciò che avevi era string, int, bool e float, i personaggi sibf sarebbero stati sufficienti. Ma con string + short, iniziano i problemi. Utilizzare l'intero nome per il prefisso o str_name per la stringa? (Mentre i nomi sono quasi sempre stringhe, no?) Cosa c'è con una classe Street? I nomi diventano sempre più lunghi e, anche se usi CamelCase, è difficile dire dove finisce il prefisso e dove inizia il nome della variabile.

 BorderLayout boderLayoutInnerPanel = new BorderLayout ();
 panelInner.addLayout (borderLayoutInnerPanel);

Ok, potresti usare le sottolineature, se non le usi già per qualcos'altro, oppure usare CamelCase se hai usato le sottolineature così a lungo:

 BorderLayout boderLayout_innerPanel = new BorderLayout ();
 panel_inner.addLayout (borderLayout_innerPanel);

 Border_layout boder_layoutInner_panel = new Border_layout ();
 panelInner.add_layout (border_layoutInner_panel);

È mostruoso e se lo fai di conseguenza, lo avrai

 for (int iI = 0; iI < iMax-1; ++iI)
     for (int iJ = iI; iJ < iMax; ++iMax) 
          int iCount += foo (iI, iJ); 

O finirai con l'uso di prefissi inutili per casi banali, come variabili-loop o count. Quando di recente hai usato un short o un long per un contatore? Se fai delle eccezioni, perderai spesso tempo, pensando di aver bisogno di un prefisso o meno.

Se hai molte variabili, vengono normalmente raggruppate in un browser oggetti che fa parte del tuo IDE. Ora se il 40% inizia con i_ per int e il 40% con s_ per stringa e sono ordinati alfabeticamente, è difficile trovare la parte significativa del nome.

L'unico posto in cui uso ancora regolarmente suffissi ungheresi o analoghi è in contesti in cui gli stessi dati semantici sono presenti in due forme diverse, come la conversione dei dati. Ciò può verificarsi nei casi in cui vi sono più unità di misura o in cui vi sono più forme (ad esempio, stringa "123" e numero intero 123).

Trovo che le ragioni fornite qui per non usarlo siano convincenti per non imporre l' ungherese agli altri, ma solo lievemente suggestivo, per aver deciso la tua pratica.

Il codice sorgente di un programma è un'interfaccia utente a sé stante - che mostra algoritmi e metadati al manutentore - e la ridondanza nelle interfacce utente è una virtù, non un peccato . Guarda, ad esempio, le immagini in " The Design of Everyday Things ", e guarda le porte etichettate "Push" che sembrano tirarle, e ai rubinetti della birra gli operatori hanno violato gli importanti controlli del reattore nucleare perché in qualche modo "passano sopra loro nell'IDE "non era abbastanza buono.

Il "passaggio con il mouse su un IDE" non è un motivo per non usare l'ungherese - solo un motivo per cui alcune persone potrebbero non trovarlo utile. Il tuo chilometraggio potrebbe essere diverso.

L'idea che l'ungherese imponga un onere di manutenzione significativo quando i tipi di variabili cambiano è sciocca: con quale frequenza cambi tipi di variabili? Inoltre, rinominare le variabili è semplice:

Basta usare l'IDE per rinominare tutte le occorrenze. -Gander, rispondendo a Goose

Se l'ungherese ti aiuta davvero a trovare rapidamente un pezzo di codice e a mantenerlo in modo affidabile, usalo. Altrimenti no. Se altre persone ti dicono che ti sbagli sulla tua esperienza, suggerirei che probabilmente sono quelli in errore.