Qual è il fascino dei sistemi ungheresi? [chiuso]

18

In Quali linee guida per la denominazione segui? , l'autore dice:

Also I prefer to code using hungarian notation from Charles Simonyi.

Mi sono imbattuto in diversi programmatori che preferiscono ancora utilizzare l'ungherese, per lo più del gusto ungherese Petzold / Systems. Pensa a dwLength = strlen(lpszName) .

Ho letto Rendi errato il codice errato , e ho compreso le motivazioni di Apps ungherese, dove dominio -tipo di informazioni è incluso nei nomi delle variabili. Ma non capisco il valore nell'attaccare il tipo di compilatore al nome.

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

EDIT: Molte risposte stanno spiegando la storia, o perché non è più rilevante, entrambe sono trattate nell'articolo che ho citato.

Mi piacerebbe davvero sentire qualcuno che lo usa ancora. Perche 'lo usi? È nel tuo standard? Lo useresti se non fosse richiesto? Lo useresti su un nuovo progetto? Quali sono i vantaggi?

    
posta AShelly 26.10.2010 - 16:36
fonte

8 risposte

38

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

  1. Per coerenza con un codice esistente quando si effettua la manutenzione.
  2. Per i controlli, ad es. "TxtFirstName". Spesso abbiamo bisogno di distinguere tra (say) "firstName" il valore e "firstName" il controllo. L'ungherese fornisce un modo conveniente per farlo. Certo, potrei digitare "firstNameTextBox", ma "txtFirstName" è altrettanto facile da capire e contiene meno caratteri. Inoltre, l'utilizzo di Ungherese significa che 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 che è stato analizzato come in un intero.

Di certo non vorrei impostare le mie idee come best practice, ma seguo queste regole perché l'esperienza mi dice che l'uso occasionale della manutenibilità del codice dei benefici in Ungheria costa poco. Detto questo, rivedo costantemente la mia pratica, quindi potrei fare qualcosa di diverso man mano che le mie idee si sviluppano.

Aggiornamento:

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

    
risposta data 27.10.2010 - 12:14
fonte
6

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 faccia riferimento a un TextBox nel tuo codice: digitando "txt" nella casella di ricerca.

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

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

Le persone non dedicheranno molto tempo a trovare dove si trova questo elemento.

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

    
risposta data 26.10.2010 - 18:06
fonte
4

Le app in Ungherese (tag che denotano proprietà semantiche di oggetti che non possono essere espresse attraverso il sistema dei tipi) erano un modo ragionevole per gestire alcuni errori comuni quando si utilizzavano le lingue debolmente tipizzate dei primi anni '80. Servono poco per le attuali lingue strongmente tipizzate.

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

Entrambi gli stili sono stati creati in Microsoft. Al giorno d'oggi, le convenzioni di denominazione di Microsoft dicono categoricamente "Non utilizzare la notazione ungherese".

    
risposta data 26.10.2010 - 19:44
fonte
4

Se trovi il giusto sistema di prefissi, potresti diffondere l'usura delle tue chiavi, il che ridurrebbe la spesa per le tastiere sostitutive.

Suppongo di poterlo espandere. Ho usato SH sul 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 variabili senza nome ma ben definite nel mio 'codice casa' per quasi altrettanto a lungo. Non ho mai perso SH.

In entrambi i casi, ho scritto un codice di protocollo che richiede tipi primitivi a dimensione fissa. Questo è il caso d'uso più vantaggioso che io possa pensare per SH. Non mi ha aiutato a capire quando sono scritto con SH, e non mi ha impedito di scrivere senza SH.

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

    
risposta data 26.10.2010 - 17:07
fonte
4

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

Il mio incarico implicava la riscrittura di un 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 di sigilli ($ stringa, @array,% hash).

In JavaScript, ho trovato SH di inestimabile per tracciare i tipi di strutture dati. Ad esempio,

var oRowData = aoTableData[iRow];

Questo recupera un oggetto da una matrice di oggetti usando un indice intero. Aderendo a questa convenzione mi sono risparmiato un bel po 'di tempo cercando i tipi di dati. Inoltre, puoi sovraccaricare i nomi delle variabili succinte ( oRow rispetto a iRow ).

tl; dr: SH può essere ottimo se hai un codice complesso in una lingua debolmente tipizzata. Ma se il tuo IDE può tracciare i tipi, preferisci quello.

    
risposta data 09.03.2013 - 22:28
fonte
2

Sono anche curioso di vedere le motivazioni. Sappiamo perché l'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 sembrava così, quindi perché cambiare le cose? Inoltre, quando costruisci sopra il codice precedente che utilizzava la notazione ungherese, sembrerebbe piuttosto strano quando improvvisamente smetti di usarlo ...

    
risposta data 26.10.2010 - 17:06
fonte
2

La notazione ungherese dei sistemi era in effetti un po 'un'arma, un'incomprensione del termine "tipo". Gli sviluppatori di sistemi l'hanno preso alla lettera come tipo di compilatore (parola, byte, stringa, ...) in opposizione al tipo di dominio delle app (indice delle righe, indice delle colonne, ...).

Ma immagino che ogni sviluppatore attraversi diverse fasi di stile che sembrano una grande idea al momento (e il tipo di prefisso sembra una buona idea per un principiante) prima di cadere nelle insidie (cambiare tipo, creare nuovo, prefissi significativi, ecc.). Quindi immagino che ci sia un'inerzia: dagli sviluppatori che non migliorano e capiscono perché è una scelta sbagliata, dagli sviluppatori con standard di codifica che impongono la pratica e da persone che usano <windows.h> . Sarebbe troppo costoso per Microsoft cambiare per sbarazzarsi della notazione del prefisso (che non è corretto in molti punti: WPARAM?).

    
risposta data 26.10.2010 - 18:05
fonte
0

C'è una cosa che manca alla gente con l'ungherese. La notazione ungherese funziona in GRANDE con il completamento automatico.

Supponiamo di avere una variabile e il nome è intHeightOfMonster.

Dì 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 completamento automatico ti suggerisce alcuni nomi di variabili.

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

Risparmia tempo.

    
risposta data 12.03.2014 - 09:27
fonte

Leggi altre domande sui tag