it-swarm.it

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

Nel mio lavoro attuale, non ci sono linee guida per la programmazione. Tutti praticamente codificano come vogliono. Va bene, dato che la compagnia è piccola.

Tuttavia, un nuovo ragazzo ha recentemente proposto di utilizzare sempre la notazione ungherese. Fino ad ora, alcuni di noi hanno usato una sorta di notazione ungherese, altri no. Sai, è una società di ingegneria, quindi gli stili di codifica non contano fino a quando gli algoritmi sono validi.

Personalmente, ritengo che queste abbreviazioni di tipo piccolo siano in qualche modo ridondanti. Un nome ben congegnato di solito recapita lo stesso messaggio. (Inoltre, la maggior parte del nostro codice deve essere eseguita su alcuni DSP strani, in cui un concetto come bool o float non esiste comunque).

Allora, cosa ne pensi della notazione ungherese? Lo usi? Perché?

37
bastibe

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

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 del originale , "reale" ungherese: Apps Hungarian.

In Apps 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 per accettare input dagli utenti: stringhe non sicure).

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

Vedi anche, l'articolo di Joel, " Far sembrare sbagliato il codice sbagliato ."

77
Dean Harding

pronome Tu verbo Dovresti avverbio Mai verbo Usa aggettivo Nome ungherese Notazione, preposizione Esso verbo Rende collettivo Tutto Avverbio Così comparativo Aggettivo del sangue Infinito To verbo Leggi.

31
smirkingman

In primo luogo:

Sai, è una società di ingegneria, quindi gli stili di codifica non contano fino a quando gli algoritmi sono validi.

Gli stili di codifica sono importanti indipendentemente dall'azienda. Sì, gli algoritmi hanno devono essere validi, ma il codice deve è gestibile da tutti, non solo dallo sviluppatore originale. Avere uno standard di codifica che include elementi di stile consente di raggiungere questo obiettivo. Non sto dicendo che tutto il codice dovrebbe avere lo stesso stile: sarebbe controproducente, ma dovrebbe esserci un certo grado di coerenza.

Ora su notazione ungherese:

Sebbene avesse i suoi usi, con un moderno IDE che supporti i comportamenti di tipo IntelliSense non è necessario includere il tipo di variabile nel suo nome. Queste informazioni sono disponibili in altri modi. può rendere più difficile la lettura del codice se in futuro dovessi cambiare il tipo di variabile.

26
ChrisF

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

21
codeape

Gran parte del dibattito sulla notazione ungherese (di sistema) dipende dall'area di lavoro. Prima ero "decisamente impossibile", ma avendo lavorato per alcuni anni in un'azienda in cui è utilizzato per lo sviluppo integrato, ne vedo alcuni vantaggi in alcune applicazioni e sicuramente è cresciuto su di me .

Sistemi ungheresi

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

App ungherese

Le app ungheresi presentano chiari vantaggi quando si tratta di applicazioni PC/Web, ad esempio offrendo una differenza visiva tra stringhe "non sicure" e stringhe "sicure" (ovvero quelle immesse da un utente e quelle che sono state salvate o lette da risorse interne o altro ). Il compilatore non è a conoscenza di questa distinzione.

Qual e il punto?

L'uso di (sistemi o app) ungherese consiste nel fare il codice sbagliato sembra sbagliato.

Se stai copiando una stringa non sicura direttamente in una stringa sicura senza scappare, sembrerà sbagliato se usi App ungherese.

Se stai moltiplicando un numero intero con segno per un numero intero senza segno, il compilatore promuoverà (spesso in silenzio) quello con segno a (un possibile enorme) senza segno, causando probabilmente un errore: i sistemi ungheresi rendono questo aspetto sbagliato.

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

Complessivamente

Nel complesso, la mia opinione è che la cosa più importante è che hai uno standard di codifica. Che si tratti di sistemi ungheresi, app ungheresi o nessuno dei due è una questione di preferenze personali o di gruppo, molto simile alla scelta dei tipi di rientri, ecc. Tuttavia, ci sono vantaggi indubbi per l'intero team di sviluppo che lavora con la stessa preferenza.

13
DrAl

Lo scopo della notazione ungherese è di codificare informazioni nell'identificatore che non potrebbero essere codificate in altro modo nel sistema di tipi. La mia opinione è che se questa informazione è abbastanza importante per essere codificata, allora è abbastanza importante per essere codificata nel sistema dei tipi, dove può essere adeguatamente controllata. E se le informazioni non sono importanti, perché diamine vuoi ingombrare il tuo codice sorgente con esso?

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

Un paio di altre risposte menzionano le Unità di misura come usi accettabili della notazione ungherese. (Sono un po 'sorpreso che nessuno abbia menzionato ancora il Mars Climate Orbiter della NASA, dal momento 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, mamma, niente ungheresi!

Se io dovessi utilizzare la notazione ungherese anziché i tipi qui, ciò non mi aiuterebbe un po ':

let mSomeLength       = 48.15
let ftSomeOtherLength = 16.2342

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

Il compilatore l'ha lasciato passare. Ora mi affido a un umano per individuare ciò che è essenzialmente un errore di tipo. Non è quello che serve per un controllo di tipo?

Ancora meglio, usando 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:

Inoltre, la maggior parte del nostro codice deve essere eseguita su alcuni DSP strani, in cui un concetto come bool o float non esiste comunque

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


PS: Consiglio vivamente di guardare Frink. Il suo manuale contiene alcune delle più fantastiche battute sulle scoregge di sempre. È anche un linguaggio piuttosto interessante :-)

9
Jörg W Mittag

DIAMINE NO!

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

Quello che dovremmo fare è nomina bene le 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 bolletta telefonica. Chiamalo phoneBill o PhoneBill.
  • Evita nomi troppo specifici. Quando qualcosa è chiaro senza ulteriori informazioni non includerlo. Se è solo una variabile dell'indice di stringa per eseguire il ciclo tra i caratteri di una stringa e la usi una sola volta nella funzione MyFunc, perché mai la chiameresti MyFuncTempStringCharacterIndex? È uno scherzo triste. Chiamalo Pos o anche i se vuoi. Nel contesto, il prossimo programmatore capirà facilmente cosa significa.

  • Quando ci si concentra su come dovrebbe essere un nome generale o specifico, considerare 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 che vengono usati allo stesso modo, allora va bene trovare un prefisso o un suffisso per indicare quella differenza. Tienilo il più corto possibile.

Come hanno già detto altri risponditori, è questo caso ristretto che ha dato il via a "App ungherese", per distinguere tra misurazioni relative alla finestra rwTabPosition e relative al documento rdTabPosition. Ma in un'applicazione che fa tutto ciò che è relativo al documento, non aggiungere alcun oggetto aggiuntivo! In effetti, perché non usare l'idea di Jörg W Mittag di farne un vero nuovo tipo? Quindi non puoi assolutamente confondere le cose.

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

vrbDo advnot vrbuse nou Nomina ungherese cnjor adjany adjother sostantivootation. prepAs come nouprogrammers, prowe vrbshould advnot verbe nouusing "nounotation" prpfor proour sostantivo nominable aggiustabile.

Con aggiungendo informazioni, ho fatto un dolore completo da leggere.

Quindi dimentica la notazione. Dimentica i prefissi speciali che aggiungi sempre. A mio avviso, l'unica vera linea guida qui dovrebbe essere:

Mantenere i nomi delle variabili come brevi il più possibile, come significativi se necessario, e sempre inequivocabile .

6
ErikE

Non ha senso in un linguaggio orientato agli oggetti: tutto è un tipo che è evidente quando si cerca di usarlo.

6
billy.bob

L'unico posto in cui Sistemi ungheresi viene messo in guardia è con un linguaggio debolmente tipizzato come C. È doppiamente importante con C perché non c'è un oggetto esplicito (ha strutture , ma tutte le funzioni sono esterne alla struttura). In qualcosa di più fortemente tipizzato come C++, Java e C # non aiuta, e di fatto peggiora le cose. Il codice cambia ed è molto più semplice cambiare un tipo che cambiare tutti i luoghi in cui si sta usando un nome variabile. È anche un lavoro superfluo che tende a 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 cui stiamo lavorando nel nostro codice. Ad esempio, stiamo usando gradienti o gradi, metri o piedi, cornici 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 punti deboli attuali e scegli uno standard ragionevole per quella parte del codice. L'eccessiva specificazione di uno standard di codifica è controproducente. C'è molto valore nell'avere nomi di variabili e campi che spiegano ciò che rappresentano e la maggior parte delle volte puoi dedurre in sicurezza il tipo dal concetto.

6
Berin Loritsch

Lo scopo di un identificatore è più importante del suo tipo. Se usi nomi descrittivi per identificatori nei tuoi programmi, non devi usare le notazioni ungheresi. isConnected è sempre più leggibile e di facile comprensione di boolConnected.

5
Mudassir

Abbiamo usato l'ungherese quando ero un programmatore C++, ed è stato grandioso. È possibile visualizzare il tipo di una variabile (ad es. 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 della variabile
  4. accedere

Quindi contava 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 descrizione comandi
  • gli editor avevano una scorciatoia "vai alla dichiarazione" e un modo rapido per tornare indietro
  • Il C++ è stato usato di meno e la maggior parte degli altri linguaggi ha meno tipi di variabili. Ad esempio, in C #, sei abbastanza sicuro che lastName sia un System.String, perché esiste solo una classe di stringhe.

Sono stato uno degli ultimi a staccarmi dall'ungherese e ora quando leggo il vecchio codice sorgente, in realtà mi dà fastidio.

2
Andomar

Odio la notazione ungherese, preferisco usare i trattini bassi per delimitare i nomi delle variabili.

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

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

Mi piace solo scrivere ThingsLikeThat quando devo essere molto descrittivo sulla variabile, perché consente di risparmiare spazio e il fatto che ci sono maiuscole lo rende più leggibile.

Quello che faccio di solito è nominare i miei metodi e le mie classi con la prima lettera maiuscola e minuscola per i nomi delle variabili e un trattino basso per i nomi delle variabili (trovo che quest'ultima sia utile).

Seriamente preferisco che le persone si preoccupino di quelle regole: usa virgole, aritmetica 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 PIÙ 90 caratteri, utilizzare argomenti multilinea per funzioni o long if:

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

Concordo con la maggior parte, è un vecchio stile.

Con i moderni IDE, un passaggio rapido sopra una variabile ti mostra il tipo.

1
ozz