Prefissi i nomi delle variabili con un'abbreviazione dei tipi di variabile? (Notazione ungherese) [chiuso]

Quando la maggior parte delle persone dice "Notazione ungherese", in realtà sta parlando di " Sistemi ungherese ".

I sistemi ungheresi sono completamente inutili e dovrebbero essere evitati. Non è necessario codificare il tipo della variabile nel suo nome. Tuttavia, Systems Hungarian è in realtà un fraintendimento di originale , "vero" ungherese: app ungherese.

In App ungherese, non si codifica il "tipo" nel nome della variabile, si codifica il "tipo" della variabile. Quindi non nWidth , ma pxWidth o emWidth (rispettivamente per "larghezza in pixel" o "larghezza in ems"). Non strName ma sName o usName (rispettivamente per "nome sicuro" o "nome non sicuro" - utile quando si accettano input dagli utenti: stringhe non sicure).

Personalmente, di solito non mi preoccupo nemmeno di entrambi. A meno che non stia facendo qualcosa che converta esplicitamente il "tipo" di un valore (ad esempio, ho usato il prefisso "px" e "em" in passato perché fa errori come pxArea = emWidth * emHeight ovvio).

Vedi anche, l'articolo di Joel, " Rendi errato il codice errato ."

pronounYou verboSpegnire avverbioNever verbUse aggettivoHungarian sostantivoNotazione, preposizioneEsemplareMakes collectivenounEverythingSo comparativoBloody aggettivoHard infinitiveTo verbRead.

In primo luogo:

You know, it's an engineering company, so coding styles do not really matter as long as the algorithms are sound.

Gli stili di codifica sono importanti indipendentemente dalla compagnia. Sì, gli algoritmi devono essere audio, ma il codice deve essere gestibile da tutti, non solo dallo sviluppatore originale. Avere uno standard di codifica che include elementi di stile va in qualche modo a farlo. Non sto dicendo che tutto il codice dovrebbe essere identico nello stile - sarebbe controproducente, ma dovrebbe esserci un certo grado di coerenza.

Ora sulla notazione ungherese:

Pur avendo i suoi usi, con un moderno IDE che supporta i comportamenti di tipo IntelliSense non è necessario includere il tipo di variabile nel suo nome. Questa informazione è disponibile per te in altri modi. Nel peggiore dei casi può rendere più difficile la lettura del codice se è necessario modificare il tipo di variabile in futuro.

Non usarlo. È ridondante e rende il codice più difficile da leggere.

Gran parte del dibattito sulla notazione ungherese (System) dipende dall'area di lavoro. Ero molto fermamente dalla parte del "no way!", Ma avendo lavorato per qualche anno in un'azienda dove è utilizzato per lo sviluppo embedded, posso vedere alcuni vantaggi in certe applicazioni e sicuramente è cresciuto su di me .

Sistemi ungheresi

Da quello che posso dire, i sistemi ungheresi tendono a essere usati molto nel campo embedded. Nelle applicazioni per PC, il compilatore tratterà molti dei problemi associati alle differenze tra (ad esempio) stringhe, numeri interi e valori in virgola mobile. Su una piattaforma profondamente integrata, sei più spesso preoccupato delle differenze tra numeri interi senza segno a 8 bit, interi con segno a 16 bit, ecc. Il compilatore (o persino il lint con regole MISRA applicate) non sempre li rileva. In questo caso avere nomi di variabili come u8ReadIndex , s16ADCValue può essere utile.

App ungherese

Le app ungheresi presentano vantaggi evidenti quando si tratta di applicazioni PC / Web, ad esempio offrono una differenza visiva tra stringhe "non sicure" e stringhe "sicure" (ovvero quelle inserite da un utente e quelle che sono state sfuggite o lette dall'interno risorse o qualsiasi altra cosa). Il compilatore non ha conoscenza di questa distinzione.

Qual è il punto?

L'uso di (Systems o Apps) ungherese consiste nel rendere il codice errato in modo errato .

Se copi una stringa pericolosa direttamente in una stringa sicura senza alcuna escaping, sembrerà errata se utilizzi Apps Hungarian.

Se stai moltiplicando un intero con segno con un numero intero senza segno, il compilatore (spesso silenziosamente) promuoverà quello firmato (un possibile enorme) senza segno, probabilmente con un errore: Sistemi ungherese lo fa sembrare sbagliato.

In entrambe queste situazioni la notazione ungherese (Apps / Systems) tende a rendere le revisioni del codice formali più veloci in quanto vi è meno riferimento al tipo di variabile.

Nel complesso

Nel complesso, la mia opinione è che la cosa più importante è che hai uno standard di codifica. Sia che utilizzi Sistemi ungheresi, Apps ungheresi o nessuno dei due è una questione di preferenze personali o di gruppo, proprio come la scelta dei tipi di indentazione, ecc. Tuttavia, ci sono indubbi vantaggi per l'intero team di sviluppo che lavora con le stesse preferenze.

Lo scopo della notazione ungherese è di codificare le informazioni nell'identificatore che non può essere altrimenti codificato nel sistema di tipi. La mia opinione è che se questa informazione è abbastanza importante da essere codificata, allora è abbastanza importante da essere codificata nel sistema di tipi, dove può essere adeguatamente controllata. E se l'informazione non è importante, allora perché diamine vuoi ingombrare il codice sorgente con esso?

Oppure, per dirla in modo più succinto: le informazioni sul tipo appartengono al sistema di tipi. (Nota: non deve essere un sistema di tipo statico . Fintanto che cattura gli errori di tipo, non mi interessa quando li cattura.)

Un paio di altre risposte menzionate Unità di misura come usi accettabili della notazione ungherese. (Sono piuttosto sorpreso che nessuno abbia menzionato ancora la NASA Mars Climate Orbiter, dato che sembra emergere continuamente nelle discussioni sulla notazione ungherese).

Ecco un semplice esempio in F #:

[<Measure>] type m
[<Measure>] type ft

let someLength      = 48.15<m>
let someOtherLength = 16.2342<ft>

someLength + someOtherLength
// someLength + someOtherLength
// -------------^^^^^^^^^^^^^^^
// error FS0001: The unit of measure 'ft' does not match the unit of measure 'm'.

Guarda, Ma, nessun ungherese!

Se I fosse per usare la notazione ungherese invece dei tipi qui, non mi sarebbe di aiuto un po ':

let mSomeLength       = 48.15
let ftSomeOtherLength = 16.2342

mSomeLength + ftSomeOtherLength
// > val it : float = 64.3842

Il compilatore lo ha lasciato passare. Ora mi affido a un umano per individuare ciò che è essenzialmente un errore di tipo. Non è quello che è un controllore di tipi?

Ancora meglio, utilizzando il linguaggio di programmazione Frink :

someLength      = 48.15m
someOtherLength = 16.2342ft

someLength + someOtherLength
// 53.09818416 m (length)

// Wanna know the answer in a good old fashioned American unit?
someLength + someOtherLength -> yd
// 58.06888031496062992

// Are you an astrophysicist?
someLength + someOtherLength -> parsec
// 1.7207949554318336148e-15

// ... or a fundmentalist Christian who refuses to use units invented 
// less than 2000 years ago?
someLength + someOtherLength -> biblicalcubits
// 95.893563822870765006

Quindi, in sintesi: non mi piace la notazione ungherese. Non dovresti mai usarlo.

Detto questo, penso che usare la notazione ungherese sia una buona idea. Aspetta, cosa?

Sì! In questo caso particolare hai menzionato:

Furthermore, most of our code has to run on some weirdo DSPs, where a concept like bool or float doesn't exist anyway

Ma questo è precisamente l'unico caso d'uso ragionevole per Notazione ungherese!

PS: raccomando vivamente di guardare Frink. Il suo manuale contiene alcune delle più fantastiche battute di scoreggia di sempre. È anche un bel linguaggio: -)

Non ha senso in un linguaggio orientato agli oggetti - tutto è un tipo che è evidente quando si prova ad usarlo.

L'unico posto in cui Systems Hungarian è waranted è con un linguaggio tipizzato debole come C. È doppiamente importante con C perché non c'è un oggetto esplicito (ha struct, ma tutte le funzioni sono esterne al struct). In qualcosa di più tipizzato come C ++, Java e C # non aiuta, e in effetti peggiora le cose. Il codice cambia ed è molto più semplice cambiare un tipo piuttosto che cambiare tutti i punti in cui stai usando un nome di variabile. È anche un lavoro occupato non necessario che tende ad essere ignorato.

Se hai unità di misura, potrebbe essere utile codificarlo in un nome, ma alla fine può anche essere un rumore extra. Ad esempio, dichiareremo l'unità di misura standard per le diverse cose con le quali stiamo lavorando nel nostro codice. Ad esempio, stiamo usando gradienti o gradi, metri o piedi, fotogrammi o millisecondi? Una volta impostato lo standard per il codice, ogni volta che leggiamo in un'unità di misura, convertiamo sempre immediatamente l'unità di misura standard per il codice.

Il mio consiglio : inizia con i tuoi attuali punti critici e scegli uno standard ragionevole per quella parte del codice. L'overspecifying di uno standard di codifica è controproducente. C'è molto valore nell'avere nomi di variabili e di campi che spiegano cosa rappresentano, e il più delle volte si può dedurre il tipo dal concetto.

HECK NO!

Non usare la notazione ungherese o qualsiasi altra notazione. Come programmatori, non dovremmo usare "notazione" per i nostri nomi di variabili.

Quello che dovremmo fare è dare un nome alle nostre variabili :

• Evita nomi troppo generici. Non nominarlo z quando si tratta di una variabile di classe che rappresenta un oggetto denominato, ad esempio una fattura telefonica. Chiamalo phoneBill o PhoneBill .

• Evita nomi troppo specifici. Quando qualcosa è chiaro senza ulteriori informazioni non includerlo. Se è solo una variabile di indice stringa per il looping dei caratteri di una stringa e la si utilizza solo una volta in funzione MyFunc, perché mai la chiameresti MyFuncTempStringCharacterIndex ? È uno scherzo triste. Chiamalo Pos o anche i se lo desideri. Nel contesto, il prossimo programmatore capirà facilmente cosa significa.

• Quando ti stai concentrando su come dovrebbe essere un nome generale o specifico, considera il dominio in cui si trova e il contesto di altri possibili significati. Nel caso ristretto in cui ci sono due elementi di tipo simile facilmente confusi e simili che vengono usati allo stesso modo, allora è bene trovare un prefisso o suffisso per indicare tale differenza. Tenerlo il più corto possibile.

Come altri rispondenti hanno detto, è questo caso stretto che ha avviato "Apps ungherese", per distinguere tra le misurazioni relative alla finestra rwTabPosition e relative al documento rdTabPosition . Ma in un'applicazione che fa tutto ciò che riguarda il documento, non aggiungere alcun extra! Infatti, perché non usare L'idea di Jörg W Mittag di farne un vero nuovo tipo? Quindi non è possibile che le cose si confondano.

In quasi tutte le aree, l'aggiunta di materiale con una densità di significato minima riduce la significatività complessiva e la facilità di comprensione. Ecco un esempio di Ben Franklin . E un altro esempio: è possibile in inglese decorare le nostre parole con la loro parte di discorso. Sono più informazioni, no? Nel caso in cui i principianti in inglese si siano confusi, potrebbe essere davvero utile per loro, giusto? Leggilo e dimmi quanto ritieni utile questo sia per la comprensione a lungo termine e l'efficiente diffusione delle informazioni:

vrbDo advnot vrbuse nouHungarian nounotation cnjor adjany adjother nounotation. prepAs nouprogrammers, prowe vrbshould advnot verbe nouusing "nounotation" prpfor proour adjvariable nounames.

Con aggiungendo informazioni, ho reso questo un dolore completo da leggere.

Quindi dimentica la notazione. Dimentica i prefissi speciali che aggiungi sempre. Secondo me, l'unica vera guida qui dovrebbe essere:

Keep variable names as short as possible, as meaningful as necessary, and always unambiguous.

Lo scopo di un identificatore è più importante del suo tipo. Se si utilizzano nomi descrittivi per identificatori nei programmi, non è necessario utilizzare le notazioni ungheresi. isConnected è sempre più leggibile e facile da capire rispetto a boolConnected .

Abbiamo usato l'ungherese quando ero un programmatore C ++, ed è stato grandioso. È possibile visualizzare il tipo di una variabile (ad esempio BSTR, CString, LPCTSTR o char *) senza cercare la dichiarazione. In quei giorni, dovresti cercare la dichiarazione facendo:

1. ctrl-casa
2. ctrl-F
3. nome variabile
4. Invio

Quindi importava un bel po '. Ma da qualche parte intorno al 2000, sono successe alcune cose:

Gli editor
• sono diventati abbastanza intelligenti da visualizzare il tipo di variabile come suggerimento
• gli editor avevano una scorciatoia "vai alla dichiarazione" e un modo rapido per tornare indietro
• C ++ è stato usato di meno, e la maggior parte delle altre lingue ha meno tipi di variabili. Ad esempio, in C #, sei sicuro che lastName è un System.String , perché c'è solo una classe di stringa.

Ero uno degli ultimi a passare dall'ungherese, e ora quando leggo il vecchio codice sorgente, in realtà mi infastidisce.

Odio la notazione ungherese, preferisco usare caratteri di sottolineatura per delimitare i nomi di variabili.

Inoltre, quando inserisci il tipo come prima lettera all'inizio del nome della variabile in questo modo: float fvelocity; vect vDirection; string ** ppszWord;

il completamento automatico li ordina tutti, e non riesci a trovare quello che vuoi, e le persone tendono a usare quello che pensano sia meglio, e non è più una notazione.

Mi piace scrivere ThingsLikeThat quando ho bisogno di essere molto descrittivo riguardo alla variabile, perché risparmia spazio e il fatto che ci siano i tappi lo rende più leggibile.

Quello che faccio di solito, è il nome dei miei metodi e classi con la prima lettera in maiuscolo, e in minuscolo per i nomi delle variabili, e un trattino basso per i nomi delle variabili (trovo che questo ultimo sia utile).

Seriamente preferisco che le persone si interessino a quelle regole: Utilizza virgole, aritmetiche e parentesi graffe con spazi pertinenti:

void f(int a, char b);
int a = b + 4 / (3 + 4);

Non più di 80 caratteri per riga o AT MOST 90 caratteri, usa gli argomenti su più righe per le funzioni o il if lungo:

if
(
    checkthat(a, b) == checkthis(b, d) &&
    checkthat(d, b) == checkthis(v, d)
)

D'accordo con la maggior parte, è un vecchio stile.

Con i moderni IDE, un rapido passaggio del mouse su una variabile ti mostra il tipo.