Buoni esempi di notazione ungherese? [chiuso]

Question

Questa domanda è quella di cercare buoni esempi di notazione ungherese, in modo da poter riunire una raccolta di questi.

Modifica: sono d'accordo sul fatto che l'ungherese per i tipi non sia quello necessario, spero in esempi più specifici in cui aumenti la leggibilità e la manutenibilità, come Joel dà nel suo articolo (come da mia risposta ).

Answer 1

L'articolo ormai classico, come menzionato in altri post ungheresi, è quello del sito di Joel:

http://www.joelonsoftware.com/articles/Wrong.html

Answer 2

Il problema con la richiesta di buoni esempi di notazione ungherese è che ognuno avrà la propria idea di come sia un buon esempio. La mia opinione personale è che la migliore Notazione ungherese non è nessun ungherese notazione . La notazione aveva originariamente lo scopo di indicare l ' uso previsto di una variabile piuttosto che il suo tipo, ma di solito è usato per informazioni sul tipo, in particolare per i controlli del modulo (ad esempio, txtFirstName per un testo casella per il nome di qualcuno.). Ciò rende il codice meno gestibile, in termini di leggibilità (ad es., "PrepIn nounTerms prepOf nounReadability") e refactoring per quando il tipo deve essere modificato (ci sono "quotaram" nell'API Win32 che hanno cambiato tipo).

Probabilmente dovresti considerare di non usarlo affatto. Esempi:

• strFirstName - questo può essere solo firstName poiché è ovvio a cosa serve, il tipo non è così importante e dovrebbe essere ovvio in questo caso. Se non ovvio, l'IDE può aiutarti in questo.
• txtFirstName - questo può cambiare in FirstNameTextBox o FirstName_TextBox . Legge meglio e sai che è un controllo e non solo il testo.
• CAccount - C è stato usato per i nomi delle classi in MFC ma non ne hai davvero bisogno. Account è abbastanza buono. Il nome maiuscolo è la convenzione standard per i tipi (e appaiono solo in luoghi specifici in modo da non confondersi con proprietà o metodi)
• ixArray (indicizza in array ) - ix è un po 'oscuro. Prova arrayIndex .
• usState (stringa non sicura per Stato ) - sembra " U.S. Stato " ;. Meglio andare con state _ UnsafeString o qualcosa del genere. Forse potresti anche avvolgerlo in una classe UnsafeString per renderlo almeno sicuro per i tipi.

Answer 3

p

(per puntatore). È praticamente l'unico prefisso che uso. Penso che aggiunga molto a una variabile (ad es. Che sia un puntatore) e quindi dovrebbe essere trattato un po 'più rispettosamente.

Ungherese per i tipi di dati è un po 'passe ora. Gli IDE possono dirti qual è il tipo (in pochi secondi passando il mouse sul nome della variabile), quindi non è così importante. Ma trattare un puntatore come se i suoi dati non fossero buoni, quindi vuoi assicurarti che sia ovvio per l'utente ciò che è anche se fa ipotesi che non dovrebbe fare durante la codifica.

Answer 4

t

Dati contaminati. Prefisso tutti i dati in arrivo da una fonte non attendibile per rendere quella variabile come contaminata. Tutti i dati contaminati devono essere ripuliti prima di eseguire qualsiasi lavoro reale su di essi.

Answer 5

È inutile usare l'ungherese per indicare i tipi perché il compilatore lo fa già per te.

Dove l'ungherese è utile è distinguere tra tipi logicamente diversi di variabili che hanno lo stesso tipo grezzo. Ad esempio, se si utilizzano ints per rappresentare le coordinate, è possibile aggiungere il prefisso x coordinate con x, y coordinate con y e distanze con d. Quindi avresti un codice simile a

dxHighlight = xStart - xEnd

yHighlight = yLocation + 3

yEnd = yStart + dyHeight

dyCode = dyField * 2

e così via. È utile perché puoi individuare gli errori a colpo d'occhio: se aggiungi un dy a un y, ottieni sempre un y. Se sottrai due x ottieni sempre un dx. Se moltiplichi una dy per uno scalare, ottieni sempre una dy. E così via. Se vedi una linea come

yTop = dyText + xButton

sai a colpo d'occhio che è sbagliato perché aggiungere un dy e una x non ha senso. Il compilatore non è riuscito a prenderti questo perché, per quanto può dire, stai aggiungendo un int a un int che va bene.

Answer 6

Non utilizzare prefissi specifici della lingua.

Usiamo:

n: Number 
p: Percentage 1=100% (for interest rates etc)
c: Currency
s: String
d: date
e: enumeration
o: object (Customer oCustomer=new Customer();)
...

Usiamo lo stesso sistema per tutte le lingue:

SQL
C
C#
Javascript
VB6
VB.net
...

È un salvavita.

Answer 7

Devil's Advocate: il miglior esempio di notazione ungherese non è usarlo. : D

Non otteniamo alcun vantaggio nell'utilizzare la notazione ungherese con IDE moderni perché conoscono il tipo. Aggiunge lavoro quando si esegue il refactoring di un tipo per una variabile poiché anche il nome dovrebbe essere cambiato (e la maggior parte delle volte, quando si ha a che fare con una variabile, si conosce comunque il tipo).

Puoi anche risolvere problemi di ordinazione con la notazione. Se usi p per il puntatore e un indirizzo per, chiami la tua variabile apStreet o paStreet? La leggibilità diminuisce quando non si ha coerenza e si deve utilizzare spazio mentale prezioso quando si deve ricordare l'ordine in cui si deve scrivere la notazione.

Answer 8

Trovo che la notazione ungherese a volte possa essere utile in linguaggi dinamici. Sto specificamente pensando al server ActionScript (essenzialmente solo JavaScript), ma potrebbe applicarsi altrove. Dato che non ci sono informazioni sul tipo reale, la notazione ungherese a volte può aiutare a rendere le cose un po 'più facili da capire.

Answer 9

L'unico ungherese che è davvero più utile è m_ per le variabili membro. (Uso anche sm_ per i membri statici, perché questo è l'ambito "altro" che esiste ancora.) Con i monitor widescreen e i compilatori che prendono nomi di variabili lunghi otto miliardi di caratteri, abbreviare i nomi dei tipi non ne vale la pena.

Answer 10

La notazione ungherese (involucro di cammello, come ho imparato) è preziosa quando si eredita un progetto software.

Sì, puoi "passare il mouse" su una variabile con il tuo IDE e scoprire che classe è, ma se stai sfogliando diverse migliaia di righe di codice non devi fermarti per quei pochi secondi - ogni .... singolo .... volta ....

Ricorda: non stai scrivendo codice per te o il tuo team da solo. Lo stai anche scrivendo per la persona che deve prendere questo codice per 2-5 anni lungo la strada e migliorarlo.

Answer 11

Ero fortemente contrario alla notazione ungherese fino a quando non ho davvero iniziato a leggerlo e cercare di capire il suo intento originale.
Dopo aver letto Joels inserisci " Wrong " e l'articolo "Riscoprire la notazione ungherese" Ho davvero cambiato idea. Fatto correttamente, credo che debba essere estremamente potente.

Wrong di Joel Spolsky
http://www.joelonsoftware.com/articles/Wrong.html

Riscoprire la notazione ungherese
http://codingthriller.blogspot.com/2007/11/rediscovering- ungherese-notation.html

Credo che la maggior parte dei Naysayer non l'abbia mai provato sul serio e non lo capisca davvero. Mi piacerebbe provarlo in un vero progetto.

Answer 12

Penso che la cosa chiave da togliere dall'articolo di Joel, linkato sopra, e dalla Notazione ungherese in generale, sia usarla quando c'è qualcosa di non ovvio nella variabile.

Un esempio, dall'articolo, è codificato rispetto a stringhe non codificate, non è che dovresti usare ungherese "noi" per stringhe non sicure e "s" per stringhe sicure, è che dovresti avere alcune identificatore per indicare che una stringa è sicura o meno. Se diventa standard, diventa facile vedere quando lo standard viene infranto.

Answer 13

m

Quando si utilizza un ORM (come l'ibernazione) si tende a gestire oggetti gestiti e non gestiti. La modifica di un oggetto gestito verrà riflessa nel database senza chiamare un salvataggio esplicito, mentre la gestione di un oggetto gestito richiede una chiamata di salvataggio esplicita. Il modo in cui gestisci l'oggetto sarà diverso a seconda di quale sia.

Answer 14

Trovo che l'unico punto utile sia quando dichiari i controlli dell'interfaccia, txtUsername, txtPassword, ddlBirthMonth. Non è perfetto, ma aiuta su grandi forme / progetti.

Non lo uso per variabili o altri elementi, solo controlli.

Answer 15

Oltre a usare 'p' per il puntatore, mi piace l'idea di usare 'cb' e 'cch' per indicare se un parametro di dimensione del buffer (o variabile) è un conteggio di byte o un conteggio di caratteri (Ho visto anche - raramente - "ce" usato per indicare un conteggio di elementi). Quindi invece di trasmettere il tipo, il prefisso trasmette l'uso o l'intento.

Lo ammetto, non uso il prefisso nel modo più coerente che dovrei probabilmente, ma mi piace l'idea.

Answer 16

Concordo sul fatto che la notazione ungherese non è più particolarmente utile. Ho pensato che la sua intenzione originale fosse quella di indicare non il tipo di dati, ma piuttosto il tipo di entità. In una sezione di codice che coinvolge i nomi di clienti, dipendenti e l'utente, ad esempio, è possibile nominare le variabili di stringa locali cusName, empName e usrName. Ciò contribuirebbe a distinguere tra nomi di variabili dal suono simile. Gli stessi prefissi per le entità verrebbero utilizzati in tutta l'applicazione. Tuttavia, quando si utilizza OO e si ha a che fare con oggetti, tali prefissi sono ridondanti in Customer.Name, Employee.Name e User.Name.

Answer 17

Il nome della variabile dovrebbe descrivere di cosa si tratta. Una buona denominazione delle variabili rende inutile la notazione ungherese.

Tuttavia, a volte potresti usare la notazione ungherese oltre a una buona denominazione delle variabili. m_numObjects ha due prefissi: " m_ e num. m_ indica l'ambito: è un membro di dati legato a questo . num indica quale valore è .

Non mi sento affatto ostacolato quando leggo " buono " codice, anche se contiene un po 'di "ungherese". A destra: leggo il codice, non lo clicco. (In effetti, non uso quasi mai il mouse durante la programmazione o qualsiasi funzione di ricerca specifica per la programmazione voodoo.)

Sono rallentato quando leggo cose come m_ubScale ( sì, ti sto guardando, Liran! ), dato che devo vedere il suo utilizzo (nessun commento!) per scoprire cosa si ridimensiona (se non del tutto?) ed è un tipo di dati (che sembra essere un carattere a virgola fissa). Un nome migliore sarebbe m_scaleFactor o m_zoomFactor, con un commento come un numero a virgola fissa o addirittura un typedef. (In effetti, un typedef sarebbe utile, poiché ci sono molti altri membri di diverse classi che usano lo stesso formato a virgola fissa. Tuttavia, alcuni non lo fanno, ma sono ancora etichettati m_ubWhats! Confusion, per non dire altro.)

Penso che l'ungherese avrebbe dovuto essere un additivo al nome della variabile, non un sostituto delle informazioni. Inoltre, molte volte la notazione ungherese non aggiunge nulla alla leggibilità della variabile, sprecando byte e tempo di lettura.

Solo il mio 2 ¢.

Answer 18

Una domanda molto antica, ma ecco un paio di "ungherese" prefissi che uso regolarmente:

  

il mio

     

per le variabili locali, per distinguere la località in cui il nome potrebbe avere senso in un contesto globale. Se vedi myFoo, viene utilizzato solo in questa funzione, indipendentemente da qualsiasi altra cosa che facciamo con Foos altrove.

myStart = GetTime();
doComplicatedOperations();
print (GetTime() - myStart);

e

  

tmp

     

per copie temporanee di valori in loop o operazioni in più passaggi. Se vedi due variabili tmpFoo a più di un paio di righe l'una dall'altra, quasi sicuramente non sono correlate.

tmpX = X; 
tmpY = Y;
X = someCalc(tmpX, tmpY);
Y = otherCalc(tmpX, tmpY);

e talvolta vecchio e nuovo per ragioni simili a tmp , di solito in cicli o funzioni più lunghi.

Answer 19

Uso sempre p per un puntatore, e basta. E questo è solo se sono in C ++. In C # non uso alcuna notazione ungherese. per es.

MyClass myClass;
MyClass* pMyClass;

Questo è tutto :)

Modifica: Oh, ho appena realizzato che è una bugia. Io uso " m_ " anche per le variabili membro. per es.

class
{
private:
bool m_myVar;
}

Answer 20

Bene, lo uso solo con le variabili di controllo della finestra. Uso btn_, txt_, lbl_ ecc per individuarli. Trovo anche utile cercare il nome del controllo digitandone il tipo (btn_ etc).

Answer 21

Non esiste un buon esempio di notazione ungherese. Basta non usarlo. Nemmeno se stai usando un linguaggio debolmente digitato. Vivrai più felice.

Ma se hai davvero bisogno di qualche motivo per non usarlo, questo è il mio preferito, estratto da questo ottimo collegamento :

Un trucco di followon nella notazione ungherese è "cambiare il tipo di una variabile ma lasciare invariato il nome della variabile". Questo è quasi invariabilmente fatto nelle app di Windows con la migrazione da Win16: - WndProc (HWND hW, WORD wMsg, WORD wParam, LONG lParam) a Win32 WndProc (HWND hW, UINT wMsg, WPARAM wParam, LPARAM lParam) che sono parole, ma si riferiscono davvero ai desideri. Il vero valore di questo approccio emerge chiaramente con la migrazione di Win64, quando i parametri saranno larghi 64 bit, ma il vecchio "w" e "l"; i prefissi rimarranno per sempre.

Answer 22

Mi ritrovo a usare 'w' che significa 'lavorare', come prefisso invece di 'temp' o 'tmp', per variabili locali che sono lì solo per jockey dati in giro, come:

Public Function ArrayFromDJRange(rangename As Range, slots As Integer) As Variant

' this function copies a Disjoint Range of specified size into a Variant Array 7/8/09 ljr

Dim j As Integer
Dim wArray As Variant
Dim rCell As Range

wArray = rangename.Value ' to initialize the working Array
ReDim wArray(0, slots - 1) ' set to size of range
j = 0

For Each rCell In rangename
    wArray(0, j) = rCell.Value
    j = j + 1
Next rCell

ArrayFromDJRange = wArray

End Function