Domanda

Vale la pena apprendere la convenzione o è una rovina per la leggibilità e la manutenibilità?

È stato utile?

Soluzione

Considerando che la maggior parte delle persone che utilizzano Notazione ungherese sta seguendo la versione fraintesa, direi che è abbastanza inutile.

Se vuoi usare la sua definizione originale, potrebbe avere più senso, ma a parte questo è per lo più zucchero sintattico.

Se leggi il Articolo di Wikipedia sull'argomento troverai due notazioni contrastanti, Notazione ungherese dei sistemi E App Notazione ungherese.

La definizione originale, buona, è la App Notazione ungherese, ma la maggior parte delle persone usa il file Notazione ungherese dei sistemi.

Come esempio dei due, considera di anteporre alle variabili l per la lunghezza, a per l'area e v per il volume.

Con tale notazione ha senso la seguente espressione:

int vBox = aBottom * lVerticalSide;

ma questo no:

int aBottom = lSide1;

Se stai mescolando i prefissi, devono essere considerati parte dell'equazione e volume = area * lunghezza va bene per una scatola, ma copiare un valore di lunghezza in una variabile di area dovrebbe sollevare alcuni campanelli d'allarme.

Sfortunatamente, l'altra notazione è meno utile, in cui le persone premettono ai nomi delle variabili il tipo del valore, in questo modo:

int iLength;
int iVolume;
int iArea;

alcune persone usano n per numero, o i per intero, f per float, s per stringa ecc.

Il prefisso originale doveva essere utilizzato per individuare problemi nelle equazioni, ma in qualche modo è stato trasformato in modo da rendere il codice leggermente più semplice da leggere poiché non è necessario cercare la dichiarazione della variabile.Con gli editor intelligenti di oggi in cui puoi semplicemente passare il mouse su qualsiasi variabile per trovare il tipo completo, e non solo un'abbreviazione, questo tipo di notazione ungherese ha perso molto del suo significato.

Ma dovresti prendere una decisione.Tutto quello che posso dire è che non uso nessuno dei due.


Modificare Giusto per aggiungere un breve avviso, mentre non lo utilizzo Notazione ungherese, utilizzo un prefisso ed è il carattere di sottolineatura.Metto il prefisso a tutti i campi privati ​​delle classi con un _ e altrimenti scrivo i loro nomi come farei con una proprietà, con la prima lettera maiuscola.

Altri suggerimenti

La Convenzione di denominazione ungherese può essere utile se utilizzata correttamente, sfortunatamente tende ad essere utilizzata in modo improprio il più delle volte.

Leggi l'articolo di Joel Spolsky Far sembrare sbagliato il codice sbagliato per una prospettiva e una giustificazione adeguate.

Essenzialmente, la notazione ungherese basata sul tipo, dove le variabili hanno come prefisso informazioni sul loro tipo (ad es.se un oggetto è una stringa, un handle, un int, ecc.) è per lo più inutile e generalmente aggiunge semplicemente un sovraccarico con pochissimi benefici.Questa, purtroppo, è la notazione ungherese con cui la maggior parte delle persone ha familiarità.Tuttavia, l'intento della notazione ungherese così come prevista è quello di aggiungere informazioni sul "tipo" di dati contenuti nella variabile.Ciò consente di partizionare tipi di dati da altri tipi di dati che non dovrebbero essere mescolati insieme se non, possibilmente, attraverso un processo di conversione.Ad esempio, coordinate basate su pixel vs.coordinate in altre unità o input non sicuri dell'utente rispetto a dati provenienti da fonti sicure, ecc.

Guardala in questo modo, se ti ritrovi a esplorare il codice per scoprire informazioni su una variabile, probabilmente dovrai modificare il tuo schema di denominazione per contenere tali informazioni, questa è l'essenza della convenzione ungherese.

Si noti che un'alternativa alla notazione ungherese consiste nell'utilizzare più classi per mostrare l'intento dell'utilizzo delle variabili anziché fare affidamento ovunque su tipi primitivi.Ad esempio, invece di avere prefissi variabili per input utente non sicuri, puoi avere una semplice classe wrapper di stringa per input utente non sicuro e una classe wrapper separata per dati sicuri.Ciò ha il vantaggio, nei linguaggi fortemente tipizzati, di avere il partizionamento imposto dal compilatore (anche in linguaggi meno fortemente tipizzati di solito è possibile aggiungere il proprio codice tripwire) ma aggiunge una quantità non trascurabile di sovraccarico.

Utilizzo ancora la notazione ungherese quando si tratta di elementi dell'interfaccia utente, in cui diversi elementi dell'interfaccia utente sono correlati a un particolare oggetto/valore, ad es.

lblFirstName per l'oggetto etichetta, txtFirstName per la casella di testo.Sicuramente non posso nominarli entrambi "FirstName" anche se Quello è la preoccupazione/responsabilità di entrambi gli oggetti.

In che modo gli altri si avvicinano alla denominazione degli elementi dell'interfaccia utente?

È inutile (e fonte di distrazione), ma è relativamente utilizzato nella mia azienda, almeno per tipi come int, stringhe, booleani e doppi.

Cose come sValue, iCount, dAmount O fAmount, E bFlag sono ovunque.

C'era una volta una buona ragione per questa convenzione.Adesso è un cancro.

Penso che la notazione ungherese sia una nota a piè di pagina interessante lungo il "percorso" verso un codice più leggibile e, se eseguita correttamente, è preferibile a non farlo.

Dicendo questo, però, preferirei farla finita, e invece di questo:

int vBox = aBottom * lVerticalSide;

Scrivi questo:

int boxVolume = bottomArea * verticalHeight;

È il 2008.Non abbiamo più schermi a larghezza fissa da 80 caratteri!

Inoltre, se stai scrivendo nomi di variabili che sono molto più lunghi, dovresti comunque considerare il refactoring in oggetti o funzioni.

Scusate se proseguo con una domanda, ma il prefisso delle interfacce con "I" si qualifica come notazione ungherese?Se è così, allora sì, molte persone lo usano nel mondo reale.In caso contrario, ignoralo.

Vedo la notazione ungherese come un modo per aggirare la capacità della nostra memoria a breve termine.Secondo gli psicologi, possiamo immagazzinare approssimativamente 7 più o meno 2 pezzi di informazione.Le informazioni extra aggiunte includendo un prefisso ci aiutano fornendo maggiori dettagli sul significato di un identificatore anche senza altro contesto.In altre parole, possiamo indovinare a cosa serve una variabile senza vedere come viene utilizzata o dichiarata.Ciò può essere evitato applicando tecniche oo come incapsulamento e il principio di responsabilità unica.

Non sono a conoscenza se questo sia stato studiato empiricamente o meno.Ipotizzerei che la quantità di sforzo aumenta notevolmente quando proviamo a comprendere classi con più di nove variabili di istanza o metodi con più di 9 variabili locali.

Al giorno d'oggi l'ambito non è più importante del tipo, ad es.

  • l per locale
  • a per argomento
  • m per membro
  • g per globale
  • eccetera

Con le moderne tecniche di refactoring del vecchio codice, cercare e sostituire un simbolo perché ne hai modificato il tipo è noioso, il compilatore rileverà le modifiche del tipo, ma spesso non rileverà l'uso errato dell'ambito, qui le convenzioni di denominazione sensate aiutano.

Quando vedo le discussioni ungheresi, sono felice di vedere le persone riflettere intensamente su come rendere il loro codice più chiaro e su come rendere più visibili gli errori.Questo è esattamente quello che dovremmo fare tutti!

Ma non dimenticare che hai alcuni strumenti potenti a tua disposizione oltre alla denominazione.

Metodo di estrazione Se i tuoi metodi stanno diventando così lunghi che le dichiarazioni delle variabili sono scomparse dalla parte superiore dello schermo, valuta la possibilità di ridurne le dimensioni.(Se hai troppi metodi, considera una nuova classe.)

Digitazione forte Se scopri che stai prendendo Caps memorizzati in una variabile intera e assegnandoli a a taglia di scarpe variabile intera, considera la possibilità di creare una classe per i codici postali e una classe per la misura delle scarpe.Quindi il tuo bug verrà rilevato in fase di compilazione, invece di richiedere un'attenta ispezione da parte di un essere umano.Quando lo faccio, di solito trovo un sacco di logica specifica per codice postale e numero di scarpe che ho disseminato nel mio codice, che posso quindi spostare nelle mie nuove classi.All'improvviso tutto il mio codice diventa più chiaro, più semplice e protetto da determinate classi di bug.Oh.

Per riassumere:sì, pensa attentamente a come usi i nomi nel codice per esprimere chiaramente le tue idee, ma guarda anche agli altri potenti strumenti OO a cui puoi fare affidamento.

Non utilizzo un senso molto rigido della notazione ungherese, ma mi ritrovo a usarla con parsimonia per alcuni oggetti personalizzati comuni per aiutarli a identificarli, e inoltre tendo ad anteporre agli oggetti di controllo della gui il tipo di controllo che sono.Ad esempio, labelFirstName, textFirstName e buttonSubmit.

Utilizzo la denominazione ungherese per gli elementi dell'interfaccia utente come pulsanti, caselle di testo ed etichette.Il vantaggio principale è il raggruppamento nel popup Intellisense di Visual Studio.Se voglio accedere alle mie etichette, inizio semplicemente a digitare lbl....e Visual Studio suggerirà tutte le mie etichette, ben raggruppate insieme.

Tuttavia, dopo aver fatto sempre più cose su Silverlight e WPF, sfruttando l'associazione dei dati, non nomino più nemmeno tutti i miei controlli, poiché non devo farvi riferimento dal codebehind (poiché in realtà non esiste più alcun codebehind ;)

Ciò che è sbagliato è mescolare gli standard.

Ciò che è giusto è assicurarsi che tutti facciano la stessa cosa.

int Box = iBottom * nVerticleSide

Il prefisso originale doveva essere usato per individuare i problemi nelle equazioni, ma in qualche modo si è trasformato nel rendere il codice leggermente più facile da leggere poiché non devi andare a cercare la dichiarazione variabile.Con i redattori intelligenti di oggi in cui puoi semplicemente passare il mouse su qualsiasi variabile per trovare il tipo completo, e non solo un'abbreviazione per questo, questo tipo di notazione ungherese ha perso molto del suo significato.

Sto rompendo un po' l'abitudine, ma il prefisso con il tipo può essere utile in JavaScript che non ha una forte digitazione delle variabili.

Quando utilizzo una lingua digitata dinamicamente, occasionalmente utilizzo l'ungherese di Apps.Per le lingue tipizzate staticamente non lo faccio.Vedi la mia spiegazione nell'altro thread.

La notazione ungherese è inutile nelle lingue indipendenti dai tipi.per esempio.Un prefisso comune che vedrai nel vecchio codice Microsoft è "lpsz" che significa "puntatore lungo a una stringa con terminazione zero".Dall'inizio del 1700 non abbiamo utilizzato architetture segmentate in cui esistono puntatori brevi e lunghi, la normale rappresentazione di stringa in C++ è sempre con terminazione zero e il compilatore è indipendente dai tipi, quindi non ci consente di applicare operazioni non di stringa al corda.Pertanto nessuna di queste informazioni è di reale utilità per un programmatore: è solo più digitazione.

Tuttavia, utilizzo un'idea simile:prefissi che chiariscono il utilizzo di una variabile.I principali sono:

  • m = membro
  • c = cost
  • s = statico
  • v = volatile
  • p = puntatore (e pp=puntatore a puntatore, ecc.)
  • i = indice o iteratore

Questi possono essere combinati, quindi una variabile membro statica che è un puntatore sarebbe "mspName".

Dove sono utili?

  • Laddove l'utilizzo è importante, è una buona idea ricordare costantemente al programmatore che una variabile è (ad esempio) un volatile o un puntatore
  • Il dereferenziamento del puntatore mi dava fastidio finché non usavo il prefisso p.Ora è davvero facile sapere quando hai un oggetto (Orange), un puntatore a un oggetto (pOrange) o un puntatore a un puntatore a un oggetto (ppOrange).Per dereferenziare un oggetto basta anteporre un asterisco per ogni p nel suo nome.Caso risolto, niente più bug di deref!
  • Nei costruttori di solito trovo che il nome di un parametro è identico al nome di una variabile membro (ad es.misurare).Preferisco usare "msize = size;" di "size = thesize" o "this.size = size".È anche molto più sicuro:Non uso accidentalmente "size = 1" (impostando il parametro) quando intendevo dire "mSize = 1" (impostando il membro)
  • Nei cicli, le mie variabili iteratrici sono tutte nomi significativi.La maggior parte dei programmatori utilizza "i" o "index" e quindi deve inventare nuovi nomi senza significato ("j", "index2") quando desidera un ciclo interno.Utilizzo un nome significativo con un prefisso i (iHospital, iWard, iPatient) in modo da sapere sempre cosa sta iterando un iteratore.
  • Nei cicli, puoi combinare diverse variabili correlate utilizzando lo stesso nome di base con prefissi diversi:Arancione arancione = pArancio[iArancio];Ciò significa anche che non si commettono errori di indicizzazione dell'array (pApple[i] sembra ok, ma scrivilo come pApple[iOrange] e l'errore è immediatamente evidente).
  • Molti programmatori utilizzeranno il mio sistema senza saperlo:aggiungendo un suffisso lungo come "Indice" o "Ptr" - non c'è alcuna buona ragione per usare una forma più lunga di un singolo carattere IMHO, quindi uso "i" e "p".Meno digitazione, più coerente, più facile da leggere.

Si tratta di un sistema semplice che aggiunge informazioni significative e utili al codice ed elimina la possibilità di molti errori di programmazione semplici ma comuni.

Lavoro per IBM da 6 mesi e non l'ho visto da nessuna parte (grazie a Dio perché lo odio). Vedo camelCase o c_style.

thisMethodIsPrettyCool()
this_method_is_pretty_cool()

Dipende dalla tua lingua e dal tuo ambiente.Di norma non lo userei, a meno che l'ambiente di sviluppo in cui ti trovi non renda difficile trovare il tipo di variabile.

Esistono anche due diversi tipi di notazione ungherese.Vedi l'articolo di Joel.Non riesco a trovarlo (i suoi nomi non li rendono esattamente facili da trovare), qualcuno ha un collegamento a quello che intendo?

Modificare:Wedge ha l'articolo che intendo nel suo post.

Forma originale (La notazione ungherese giusta :)) dove prefisso significa tipo (cioèlunghezza, quantità) del valore memorizzato dalla variabile è OK, ma non necessario in tutti i tipi di applicazioni.

La forma popolare (The Wrong Ungherese Notation) dove il prefisso significa tipo (String, int) è inutile nella maggior parte dei linguaggi di programmazione moderni.

Soprattutto con nomi senza significato come strA.Non riesco a capire che noi persone usiamo nomi senza significato con prefissi lunghi che non danno nulla.

Utilizzo il tipo basato (Systems HN) per i componenti (ad esempio editFirstName, lblStatus ecc.) poiché migliora il funzionamento del completamento automatico.

A volte utilizzo l'app HN per le variabili in cui le informazioni sul tipo sono insufficienti.Cioè fpX indica una variabile a punta fissa (tipo int, ma non può essere mescolata e abbinata con un int), rawInput per stringhe utente che non sono state convalidate ecc.

Essendo un programmatore PHP in cui è digitato in modo molto approssimativo, non ho intenzione di usarlo.Tuttavia occasionalmente identificherò qualcosa come un array o come un oggetto a seconda delle dimensioni del sistema e dell'ambito della variabile.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top