Qual è il vantaggio di non utilizzare la notazione ungherese?

Perché la sua intenzione originale (vedi link e link ) è stato frainteso ed è stato utilizzato (ab) per aiutare le persone a ricordare che tipo è una variabile quando la lingua che usano non è tipizzata staticamente. In qualsiasi linguaggio tipizzato in modo statico non è necessario aggiungere la zavorra di prefissi per indicare quale sia il tipo di variabile. In molti linguaggi di script non tipizzati può essere d'aiuto, ma è stato spesso abusato al punto da diventare totalmente poco maneggevole. Sfortunatamente, invece di tornare all'intento originario della notazione ungherese, le persone si sono appena trasformate in una di quelle cose "cattive" che dovresti evitare.

In breve, la notazione ungherese intendeva prefisso variabili con una certa semantica. Ad esempio, se hai le coordinate dello schermo (a sinistra, in alto, a destra, in basso), prefissi le variabili con posizioni di schermo assolute con " abs " e le variabili con posizioni relative a una finestra con " rel ". In questo modo sarebbe ovvio per ogni lettore quando si passa una coordinata relativa a un metodo che richiede posizioni assolute.

aggiornamento (in risposta al commento di delnan)

IMHO la versione abusata è evitata come la peste perché

• complica la denominazione. Quando (ab) si usa la notazione ungherese ci saranno sempre discussioni su come devono essere specifici i prefissi. Ad esempio: listboxXYZ o MyParticularFlavourListBoxXYZ .
• rende i nomi delle variabili più lunghi senza aiutare a capire a cosa serve la variabile.
• sconfigge l'oggetto dell'esercizio quando per evitare lunghi prefissi questi vengono abbreviati e serve un dizionario per sapere cosa significa ogni sigla. ui è un intero senza segno? un'interfaccia conteggiata senza riferimento? qualcosa a che fare con le interfacce utente? E quelle cose possono ottenere lunghe . Ho visto prefissi di più di 15 personaggi apparentemente casuali che dovrebbero trasmettere il tipo esatto della var ma in realtà solo mistificare.
• diventa obsoleto velocemente. Quando cambi il tipo di una variabile, invariabilmente la gente (lol) dimentica di aggiornare il prefisso per riflettere la modifica, o deliberatamente non la aggiorna perché ciò innescherebbe cambiamenti di codice ovunque la var sia usata ...
• complica parlare di codice perché "@g". ha detto: nomi variabili con notazione ungherese sono in genere zuppa alfabeto di difficile pronuncia. Questo inibisce la leggibilità e la discussione del codice, perché non puoi "dire" nessuno dei nomi.
• ... molto altro che non riesco a ricordare al momento. Forse perché ho avuto il piacere di non dover affrontare la notazione ungherese maltrattata per un lungo periodo ...

La notazione ungherese è un anti-modello di denominazione negli ambienti di programmazione dei giorni moderni e forma di tautologia .

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

Violare il principio ASCIUTTA. Se devi anteporre le tue tabelle al database con un'abbreviazione per ricordarti che si tratta di una tabella, allora sicuramente non stai nominando le tue tabelle abbastanza descrittivamente abbastanza. Lo stesso vale per ogni altra cosa con cui stai facendo questo. È solo una digitazione in più e funziona senza guadagno o vantaggio con un moderno ambiente di sviluppo.

Wikipedia ha una lista di vantaggi e svantaggi della notazione ungherese e può quindi fornire probabilmente la risposta più completa a questa domanda. Anche le opinioni degne di nota sono una lettura piuttosto interessante.

Il vantaggio di non usando la notazione ungherese è fondamentalmente solo evitamento dei suoi svantaggi:

• The Hungarian notation is redundant when type-checking is done by the compiler. Compilers for languages providing type-checking ensure the usage of a variable is consistent with its type automatically; checks by eye are redundant and subject to human error.

• All modern Integrated development environments display variable types on demand, and automatically flag operations which use incompatible types, making the notation largely obsolete.

• Hungarian Notation becomes confusing when it is used to represent several properties, as in a_crszkvc30LastNameCol: a constant reference argument, holding the contents of a database column LastName of type varchar(30) which is part of the table's primary key.

• It may lead to inconsistency when code is modified or ported. If a variable's type is changed, either the decoration on the name of the variable will be inconsistent with the new type, or the variable's name must be changed. A particularly well known example is the standard WPARAM type, and the accompanying wParam formal parameter in many Windows system function declarations. The 'w' stands for 'word', where 'word' is the native word size of the platform's hardware architecture. It was originally a 16 bit type on 16-bit word architectures, but was changed to a 32-bit on 32-bit word architectures, or 64-bit type on 64-bit word architectures in later versions of the operating system while retaining its original name (its true underlying type is UINT_PTR, that is, an unsigned integer large enough to hold a pointer). The semantic impedance, and hence programmer confusion and inconsistency from platform-to-platform, is on the assumption that 'w' stands for 16-bit in those different environments.

• Most of the time, knowing the use of a variable implies knowing its type. Furthermore, if the usage of a variable is not known, it can't be deduced from its type.

• Hungarian notation strongly reduces the benefits of using feature-rich code editors that support completion on variable names, for the programmer has to input the whole type specifier first.

• It makes code less readable, by obfuscating the purpose of the variable with needless type and scoping prefixes.

• The additional type information can insufficiently replace more descriptive names. E.g. sDatabase doesn't tell the reader what it is. databaseName might be a more descriptive name.

• When names are sufficiently descriptive, the additional type information can be redundant. E.g. firstName is most likely a string. So naming it sFirstName only adds clutter to the code.

Io stesso non uso questa notazione, perché non mi piace il rumore tecnico non necessario. Conosco quasi sempre il tipo con cui ho a che fare e voglio un linguaggio pulito nel mio modello di dominio, ma scrivo principalmente in lingue statiche e strongmente tipizzate.

Come problema specifico di MS SQL Server:

Any stored procedures prefixed with 'sp_' are first searched for in the Master database rather than the one it is created in. This will cause a delay in the stored procedure being executed.

IMO il più grande vantaggio di non usare ungherese è il fatto che ti costringe a usare nomi significativi . Se si assegnano nomi alle variabili correttamente, è necessario sapere immediatamente di che tipo si tratta o essere in grado di dedurlo abbastanza rapidamente in qualsiasi sistema ben progettato. Se devi fare affidamento su str o bln o peggio di tutti i prefissi obj per sapere di che tipo è una variabile, direi che indica un problema di denominazione - nomi di variabili poveri in generale o troppo generici per trasmettere significato.

Ironia della sorte, per esperienza personale lo scenario principale che ho visto ungherese usato è la programmazione "cargo-cult" (vale a dire un altro codice lo usa, quindi continuiamo a usarlo solo perché) o in VB.NET per aggirare il fatto la lingua non fa distinzione tra maiuscole e minuscole (es. Person oPerson = new Person perché non puoi usare Person person = new Person e Person p = new Person è troppo vago); Ho anche visto il prefisso "il" o "mio" invece (come in Person thePerson = new Person o il più brutto Person myPerson = new Person ), in quel caso particolare.

Aggiungerò il solo tempo in cui uso l'ungherese tende ad essere per i controlli ASP.NET e questa è davvero una questione di scelta. Trovo molto brutto digitare TextBoxCustomerName o CustomerNameTextBox rispetto al più semplice txtCustomerName , ma anche questo sembra "sporco". Sento che alcuni tipo di convenzione di denominazione dovrebbero essere usati per i controlli in quanto possono esserci più controlli che visualizzano gli stessi dati.

Mi concentrerò su SQL Server da quando lo hai menzionato. Non vedo alcun motivo per mettere 'tbl' di fronte a un tavolo. Puoi solo guardare qualsiasi codice tSQL e distinguere una tabella in base a come viene utilizzata. Mai Select from stored_procedure. o Select from table(with_param) come se fosse un UDF o Execute tblTableOrViewName come una stored procedure.

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 può farti risparmiare il tempo di cercarlo in SSMS (sotto la tabella o le viste?), Ma questo è tutto.

Le variabili possono presentare un problema, ma devono essere dichiarate e in realtà, fino a che punto della dichiarazione dichiarativa pensi di utilizzare una variabile? Scorrere alcune righe non dovrebbe essere un grosso problema se non stai scrivendo procedure molto lunghe. Potrebbe essere una buona idea spezzare un po 'il lungo codice.

Ciò che descrivi è un dolore, ma la soluzione di notazione ungherese in realtà non risolve il problema. Puoi guardare il codice di qualcun altro e scoprire che il tipo di variabile può essere cambiato che ora richiede una modifica al nome della variabile. Solo un'altra cosa da dimenticare. E se utilizzo un VarChar, è necessario verificare la dichiarazione di dichiarazione per conoscere la dimensione. I nomi descrittivi ti porteranno probabilmente oltre. @PayPeriodStartDate praticamente si spiega da solo.

Un'altra cosa da aggiungere è che, quali abbreviazioni useresti per un intero framework come .NET? Sì, è così semplice ricordare che btn rappresenta un pulsante e txt rappresenta una casella di testo. Tuttavia, che cosa hai in mente per qualcosa come StringBuilder ? %codice%? Che dire di strbld ? Usi qualcosa di simile:

CompositeWebControl comWCMyControl = new CompositeWebControl();

Una delle inefficienze della notazione ungherese era che, avendo strutture sempre più grandi, non solo non si aggiungeva un ulteriore vantaggio, ma si aggiungeva anche una maggiore complessità per gli sviluppatori, perché ora dovevano imparare i prefissi non standard più e altro ancora.

Per quanto riguarda il mio modo di vedere le cose, la notazione ungherese è un trucco 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. Nel rant di Joel Spolsky su Notazione ungherese fornisce un esempio di utilizzo per rilevare possibili attacchi XSS indicando che una variabile o una funzione non è sicura (noi) o sicura (s), ma che si basa ancora sul programmatore per verificare visivamente. Se invece si dispone di un sistema di tipi estendibile, è sufficiente creare due nuovi tipi, UnsafeString e SafeString, quindi utilizzarli come appropriato. Come bonus, il tipo di codifica diventa:

SafeString encode(UnsafeString)

e non accedere ai componenti 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 prendono solo istanze di SafeString, diventa impossibile generare una stringa senza escape [annulla shenanigans con conversioni come StringToSafeString (someUnsafeString.ToString ())].

Dovrebbe essere ovvio il motivo per cui consentire al sistema di tipo di controllare il tuo codice è superiore a provare a farlo a mano, o forse guardare in questo caso.

In una lingua come C ovviamente, sei fregato che un int è 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, I.E. prefisso con il tipo di variabile, è semplicemente stupido e incoraggia pratiche pigri come la denominazione delle variabili uivxwFoo invece di qualcosa di significativo come countOfPeople.

La notazione ungherese è quasi completamente inutile in un linguaggio tipizzato staticamente. È una funzionalità IDE di base per mostrare il tipo di una variabile spostando il mouse su di essa, o con altri mezzi; inoltre puoi vedere di che tipo si tratta osservando alcune righe su dove è stato dichiarato, se non c'è un'inferenza di tipo. L'intero punto di inferenza del tipo è di non avere il rumore del tipo ripetuto ovunque, quindi la notazione ungherese è solitamente vista come una cosa negativa nelle lingue con inferenza di tipo.

Nei linguaggi tipizzati dinamicamente, può aiutare a volte, ma a me sembra unidiomatico. Hai già rinunciato a limitare le tue funzioni a domini / codici specifici; se tutte le variabili sono denominate con notazione ungherese, allora stai solo riproducendo ciò che un sistema di tipi 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 ho mai usato la notazione ungherese era in codice assembly, perché stavo cercando di recuperare ciò che avrei ottenuto se avessi un sistema di tipi, ed è stata la prima cosa che abbia mai codificato.

Ad ogni modo, potrei fregarmene di meno di quello che le persone chiamano le loro variabili, il codice probabilmente sarà ancora altrettanto incomprensibile. Gli sviluppatori sprecano troppo tempo su cose come lo stile e nomi di variabili, e alla fine della giornata hai ancora un sacco di librerie con convenzioni completamente diverse nella tua lingua. Sto sviluppando un linguaggio simbolico (cioè non basato su testo) dove non ci sono nomi di variabili, solo identificatori univoci e nomi suggeriti per variabili (ma la maggior parte delle variabili non ha ancora un nome suggerito perché lì semplicemente non esiste un nome ragionevole per loro); quando si verifica un codice non affidabile, non è possibile dipendere dai nomi delle variabili.

Come al solito in questo caso, invierò 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 cliccarci sopra e verrà visualizzato, nella maggior parte dei moderni IDE. Non so quali strumenti stai usando, ma l'ultima volta che sono stato costretto a lavorare in un ambiente che non forniva questa funzionalità era nel 20 ° secolo, la lingua era COBOL, oops no era Fortran, e il mio capo non ho capito perché ho lasciato.

2 / I tipi possono cambiare durante il ciclo di sviluppo. Un numero intero a 32 bit potrebbe diventare un numero intero a 64 bit, 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 karma negativo.

3) Quello che stai chiedendo è in realtà una ridondanza. La ridondanza non è un modello di progettazione o un'abitudine molto buoni. Persino gli umani sono riluttanti a troppa ridondanza. Persino gli umani sono riluttanti a troppa ridondanza.

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

Se la tua definizione di variabile non è visibile, di solito, hai dei problemi.
E se le tue funzioni non seguono alcune convenzioni memorabili , di nuovo, un grosso problema.

Questo è ... il motivo per cui molti ambienti di lavoro lo eliminano, suppongo.

È originato dalle lingue che necessario .
In periodi di bonanza di variabili globali . (per mancanza di alternative)
Ci è servito bene.

L'unico vero uso che abbiamo per questo oggi è Joel Spolsky uno .
Per tenere traccia di alcuni attributi particolari della variabile, come la sua sicurezza .

( ad es. "La variabile safeFoobar ha una luce verde da iniettare in una query SQL?
- Come si chiama safe , sì ")

Altre risposte hanno parlato delle funzionalità dell'editor che hanno aiutato a vedere il tipo di una variabile mentre ci si sposta sopra. Dal mio punto di vista, anche quelli sono un po ' problematici per la sanità del codice . Credo che abbiano utilizzato solo per il refactoring , come anche molte altre funzioni (come la funzione di folding) e non dovrebbero essere utilizzate 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 uso la notazione ungherese per gli oggetti DDL che vengono usati raramente nel codice, ma che altrimenti colliderebbero in spazi dei nomi. Principalmente questo si riduce al prefisso degli indici e dei vincoli con il loro tipo (PK, UK, FK e IN). Utilizza un metodo coerente per denominare questi oggetti e dovresti essere in grado di eseguire alcune validazioni 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)

app ungherese O.T.O.H. prefissi con uso della variabile (ad esempio scrxMouse è la coordinata dell'asse sullo schermo può essere un tipo int, short, long o anche un tipo personalizzato (typedef ti permetterà anche di cambiarlo facilmente))

l'incomprensione dei sistemi è ciò che ha distrutto l'ungherese come best practice

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++;

Il int non ci dice molto. Il semplice fatto che qualcosa sia un int non ci dice cosa c'è dentro. Ora supponiamo, invece, lo chiamiamo così:

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

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

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

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

Questo va bene finché sai cosa significa c . Ma dovresti avere una tabella standard di prefissi, e tutti dovrebbero conoscerli, e ogni nuova persona dovrebbe impararli per capire il tuo codice. Mentre customerCount o countOfCustomers è abbastanza ovvio a prima vista.

L'ungherese aveva uno scopo in VB prima della coesistenza di Option Strict On , perché in VB6 e precedenti (e in VB .NET con Option Strict Off ) VB costringeva i tipi, quindi puoi fare questo:

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

Questo è male, ma il compilatore non ti direbbe così. Quindi se hai usato l'ungherese, almeno avresti qualche indicatore di quello che stava succedendo:

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

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

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

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

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

Okay: potresti usare le sottolineature, se non le usi già per qualcos'altro, o usare CamelCase se hai usato le sottotitoli per così tanto tempo:

 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, avrai

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

O terminerai usando prefissi inutili per casi banali, come variabili loop o count . Quando hai usato recentemente un contatore breve o lungo? Se fai delle eccezioni, perdi spesso tempo, pensando di aver bisogno di un prefisso o meno.

Se hai molte variabili, vengono normalmente raggruppate in un browser degli 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 utilizzo ancora regolarmente suffissi ungheresi o analoghi si trova in contesti in cui gli stessi dati semantici sono presenti in due forme diverse, come la conversione dei dati. Questo può essere nei casi in cui ci sono più unità di misura o dove ci sono più moduli (ad esempio, stringa "123" e intero 123).

Trovo le ragioni fornite qui per non usarlo irresistibilmente per non imporre ungherese sugli altri, ma solo leggermente suggestivo, per decidere sulla tua pratica.

Il codice sorgente di un programma è un'interfaccia utente a sé stante - visualizzazione di algoritmi e metadati per il maintainer - e ridondanza nelle interfacce utente è una virtù, non un peccato . Vedi, ad esempio, le immagini in " Il design delle cose quotidiane ", e guarda le porte etichettate "Push" sembra che tu li tiri, e ai rubinetti della birra gli operatori si sono attaccati agli importanti controlli dei reattori nucleari perché in qualche modo "sorvolandoli nell'IDE" non era abbastanza buono.

Il "passaggio del mouse in un IDE" è non un motivo per non utilizzare l'ungherese - solo un motivo per cui alcuni potrebbero non essere utili. Il tuo chilometraggio potrebbe essere diverso.

L'idea che l'ungherese imponga un onere di manutenzione significativo quando i tipi variabili cambiano è sciocca - quanto spesso cambi tipi variabili? Inoltre, la ridenominazione delle variabili è semplice:

Just use the IDE to rename all the occurences. -Gander, replying to Goose

Se l'ungherese ti aiuta davvero a digerire velocemente un pezzo di codice e a mantenerlo in modo affidabile, usalo. Se no, non farlo. Se altre persone ti dicono che hai torto riguardo la tua esperienza, suggerirei che probabilmente sono quelli per errore.