Qual è il fascino dei sistemi ungheresi? [chiuso]

In Quali linee guida per i nomi segui? , dice l'autore:

Inoltre preferisco codificare usando la notazione ungherese di Charles Simonyi.

Ho incontrato diversi programmatori che preferiscono ancora usare l'ungherese, principalmente dal sapore ungherese Petzold / Systems. Pensare dwLength = strlen(lpszName).

Ho letto Far sembrare sbagliato il codice sbagliato e capisco la logica di Apps Hungarian, in cui le informazioni sul tipo di dominio sono incluse nei nomi delle variabili. Ma non capisco il valore nell'attaccare il tipo di compilatore al nome.

Perché i programmatori continuano a usare questo stile di notazione? È solo inerzia? Ci sono dei vantaggi che superano la ridotta leggibilità? Le persone imparano semplicemente a ignorare i decoratori durante la lettura del codice e, in tal caso, come continuano ad aggiungere valore?

EDIT: molte risposte spiegano la storia, o perché non è più pertinente, entrambi sono trattati nell'articolo che ho citato.

Mi piacerebbe davvero sentire qualcuno là fuori che lo utilizza ancora. Perche 'lo usi? È nel tuo standard? Lo useresti se non fosse richiesto? Lo useresti su un nuovo progetto? Quali vedi come vantaggi?

Al momento uso ancora l'ungherese per esattamente tre motivi , evitando giudiziosamente per tutto il resto:

1. Per coerenza con una base di codice esistente durante la manutenzione.
2. Per i controlli, ad es. "TxtFirstName". Spesso è necessario distinguere tra (ad esempio) "firstName" il valore e "firstName" il controllo. L'ungherese offre un modo conveniente per farlo. Certo, potrei digitare "firstNameTextBox", ma "txtFirstName" è altrettanto facile da capire ed è meno caratteri. Inoltre, l'uso dell'ungherese significa che i controlli dello stesso tipo sono facili da trovare e sono spesso raggruppati per nome nell'IDE.
3. Quando due variabili hanno lo stesso valore ma differiscono per tipo. Ad esempio, "strValue" per il valore effettivamente digitato dall'utente e "intValue" per lo stesso valore una volta analizzato come intero.

Certamente non vorrei impostare le mie idee come best practice, ma seguo queste regole perché l'esperienza mi dice che è un uso occasionale della manutenibilità del codice ungherese dei vantaggi, ma costa poco. Detto questo, rivedo costantemente la mia pratica, quindi potrei fare qualcosa di diverso mentre le mie idee si sviluppano.

Aggiornare:

Ho appena letto un articolo perspicace di Eric Lippert, che spiega come l'ungherese può aiutare a far apparire sbagliato il codice sbagliato. Vale la pena leggere.

Non sono un grande fan dell'uso della notazione ungherese, ma la penso in questo modo:

• Possiamo anche notare che è più veloce trovare una stringa che fa riferimento a una TextBox nel tuo codice: digitando "txt" nella casella di ricerca.

Non immaginare il contrario, dove ogni elemento ha il suo nome. Potrebbe essere più lento per te trovare dove vuoi andare, giusto?

Lo stesso vale per ddl quando vogliamo fare riferimento a un DropDownList, è più facile o no? :)

Le persone non passeranno così tanto tempo a trovare dov'è questo elemento.

L'uso del prefisso non è utilizzabile per compilatori di linguaggi moderni come C #, ma è utilizzabile (leggibile) per gli esseri umani.

Le app ungheresi (tag per indicare le proprietà semantiche degli oggetti che non possono essere espresse attraverso il sistema dei tipi) erano un modo ragionevole per affrontare alcuni errori comuni quando si usano le lingue debolmente tipizzate dei primi anni '80. Servono poco allo scopo nelle lingue fortemente tipizzate di oggi.

I sistemi ungheresi (tag per indicare in modo ridondante il tipo dichiarato di un oggetto) non hanno mai avuto alcuno scopo se non quello di imporre un aspetto superficialmente uniforme su una base di codice. È stato creato e diffuso da gestori non tecnici e programmatori inesperti, che hanno frainteso l'intento di Apps Hungarian e credevano che la qualità del codice potesse essere migliorata da complesse linee guida per la codifica.

Entrambi gli stili hanno avuto origine in Microsoft. In questi giorni, le convenzioni di denominazione di Microsoft dicono categoricamente "Non usare la notazione ungherese".

Se trovi il giusto sistema di prefissi, potresti diffondere l'usura dei tuoi tasti, il che ridurrebbe le spese per le tastiere sostitutive.

Suppongo che potrei espandermi su questo. Ho usato SH nel mio posto di lavoro per l'ultimo, oh, dieci anni circa (perché è nel nostro standard). Non ha mai aiutato a risolvere un problema.

D'altra parte, ho usato le variabili disadorno ma ben nominate nel mio "codice home" per quasi altrettanto tempo. Non ho mai perso SH.

In entrambi i casi, ho scritto un codice di protocollo che richiede tipi primitivi di dimensioni fisse. Questo è il caso d'uso più utile che mi viene in mente per SH. Non ha aiutato quello che posso dire quando scritto con SH, e non mi ha impedito quando è scritto senza SH.

Quindi, in conclusione, l'unica differenza che posso vedere è l'usura della tastiera.

In realtà ho iniziato a usare SH nel nuovo codice che ho scritto questo mese.

Il mio incarico prevedeva la riscrittura del codice Perl in JS in modo che potesse essere spostato sul lato client della nostra applicazione web. In Perl, SH non è generalmente richiesto a causa dei sigilli ($ stringa, @array,% hash).

In JavaScript, ho trovato SH prezioso per tenere traccia dei tipi di strutture di dati. Per esempio,

var oRowData = aoTableData[iRow];

Ciò recupera un oggetto da una matrice di oggetti utilizzando un indice intero. L'adesione a questa convenzione mi ha fatto risparmiare un po 'di tempo a cercare tipi di dati. Inoltre, puoi sovraccaricare i nomi delle variabili sintetiche ( oRowvs.iRow ).

tl; dr: SH può essere eccezionale quando hai un codice complesso in un linguaggio debolmente tipizzato. Ma se il tuo IDE è in grado di tracciare i tipi, preferiscilo.

Sono anche curioso di vedere la logica. Sappiamo perché lo hanno usato in passato: mancanza di supporto IDE per le informazioni sul tipo. Ma ora? In poche parole, penso che sia una tradizione. Il codice C ++ è sempre stato così, quindi perché cambiare le cose? Inoltre, quando si costruisce sopra il codice precedente che utilizzava la notazione ungherese, sembrerebbe abbastanza strano quando improvvisamente smetti di usarlo ...

La notazione ungherese di Systems era in realtà un po 'un errore, un fraintendimento del termine "tipo". Gli sviluppatori di sistemi lo hanno preso letteralmente come tipo di compilatore (parola, byte, stringa, ...) rispetto al tipo di dominio delle app (indice di riga, indice di colonna, ...).

Ma suppongo che ogni sviluppatore attraversi diverse fasi di stile che sembrano un'ottima idea all'epoca (e il tipo di prefisso sembra una buona idea per un principiante) prima di cadere nelle insidie ​​(cambiare tipo, creare nuovi prefissi significativi, eccetera). Quindi suppongo che ci sia un'inerzia: dagli sviluppatori che non migliorano e capiscono perché è una scelta sbagliata, dagli sviluppatori bloccati con standard di codifica che impongono la pratica e dalle persone che usano <windows.h>. Sarebbe troppo costoso per Microsoft cambiare per eliminare la notazione del prefisso (che non è corretta in molti punti: WPARAM?).

C'è una cosa che manca all'ungherese. La notazione ungherese in realtà funziona benissimo con il completamento automatico.

Supponi di avere una variabile e che il nome sia intHeightOfMonster.

Di 'che hai dimenticato il nome della variabile

Potrebbe essere heightOfMonster o MonsterHeight o MeasurementMonsterHeight

Vuoi essere in grado di digitare una lettera e ottenere il suggerimento di completamento automatico per te alcuni nomi di variabili.

Sapendo che heightOfMonster è un int, basta digitare i e voilà.

Risparmia tempo.