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

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 simile boolo floatnon esiste comunque).

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

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 di variabile nel nome. Tuttavia, Systems Hungarian è in realtà un fraintendimento dell'originale , "vero" ungherese: Apps Hungarian.

In Apps ungherese, non si codifica il "tipo" nel nome della variabile, si codifica il "tipo" della variabile. Quindi no nWidth, ma pxWidtho emWidth(rispettivamente per "larghezza in pixel" o "larghezza in ems"). Non strNamema sNameo 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 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 pxArea = emWidth * emHeightovvi).

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

pronomeYou verbo Dovrebbe avverbio Mai verbo Usa aggettivo Nome unghereseNotazione, preposizioneIt verbo Fa collezionare tutto Avverbio Tutto Comparativo Aggettivo del sangue Infinito To verbo Leggi.

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 devono essere validi, ma il codice deve essere 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 IDE moderno che supporti i comportamenti di tipo IntelliSense non è necessario includere il tipo di variabile nel suo nome. Questa informazione è a tua disposizione in altri modi. Nel peggiore dei casi può rendere più difficile la lettura del codice se in futuro dovessi cambiare il tipo di variabile.

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

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 (es.) 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 avere nomi di variabili come u8ReadIndex, s16ADCValuepuò 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 far sembrare sbagliato il codice 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 determinati vantaggi per l'intero team di sviluppo che lavora con la stessa preferenza.

Lo scopo della notazione ungherese è di codificare informazioni nell'identificatore che non possono essere codificate in altro modo nel sistema di tipi. La mia opinione è che se queste informazioni sono abbastanza importanti da essere codificate, allora è abbastanza importante da essere codificate nel sistema dei tipi, dove possono essere adeguatamente controllate. 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 gli errori di tipo, non mi interessa quando li rileva.)

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 usare ungherese notazione invece di tipi qui, che non mi avrebbe aiutato 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 essere umano per individuare ciò che è essenzialmente un errore di tipo. Non è quello che serve per un controllo di tipo?

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

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 è esattamente l'unico caso d'uso sensato per la 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 :-)

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

L'unico posto in cui viene garantito il sistema ungherese è con un linguaggio debolmente tipizzato come C. È doppiamente importante con C perché non c'è un oggetto esplicito (ha delle 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 di variabile. È anche un lavoro superfluo che tende a essere ignorato.

Se si dispone di 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 attuali punti deboli 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.

DIAMINE 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 è nominare bene le nostre variabili :

• Evita nomi troppo generici. Non nominarlo zquando si tratta di una variabile di classe che rappresenta un oggetto denominato, ad esempio, una bolletta telefonica. Chiamalo phoneBillo PhoneBill.

• Evita nomi troppo specifici. Quando qualcosa è chiaro senza ulteriori informazioni non includerlo. Se è solo una variabile di 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 mai MyFuncTempStringCharacterIndex? È uno scherzo triste. Chiamalo Poso anche ise ti piace. 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 detto altri risponditori, è questo caso ristretto che ha dato il via a "App ungherese", per distinguere tra misurazioni relative alla finestra rwTabPositione 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 crearne uno nuovo? 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 un 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 nominations adjvariable.

Con l' aggiunta di informazioni, ho fatto che 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:

Mantieni i nomi delle variabili il più brevi possibile, il più significativo possibile e sempre inequivocabile .

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 facile da capire di boolConnected.

Abbiamo usato l'ungherese quando ero un programmatore C ++, ed è stato fantastico. È possibile visualizzare il tipo di una variabile (fe 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 delle altre lingue ha meno tipi di variabili. Ad esempio, in C #, sei abbastanza sicuro che lastNamesia un System.String, perché c'è 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.

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 utile quest'ultima).

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 PIÙ 90 caratteri, utilizzare argomenti a più righe per funzioni o long if:

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

Concordo con la maggior parte, è un vecchio stile.

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