Notație maghiară - Hungarian notation

Notarea maghiară este o convenție de numire a identificatorului în programarea computerizată , în care numele unei variabile sau funcții indică intenția sau felul acesteia, iar în unele dialecte tipul acesteia . Notația maghiară originală folosește intenția sau felul în convenția sa de denumire și este uneori numită Apps Hungarian, deoarece a devenit populară în divizia Microsoft Apps în dezvoltarea Word, Excel și a altor aplicații. Pe măsură ce divizia Microsoft Windows a adoptat convenția de numire, aceștia au folosit tipul de date propriu-zis pentru denumire, iar această convenție a devenit răspândită pe scară largă prin intermediul API-ului Windows; aceasta este uneori numită sisteme notație maghiară.

Simonyi : ... BCPL [avea] un singur tip care era un cuvânt pe 16 biți ... nu că contează.

Booch : Dacă nu continuați notația maghiară.

Simonyi : Absolut ... am trecut la limbile tastate prea târziu ... Dar ... ne-am uita la un singur nume și ți-aș spune exact multe despre asta ...

Notarea maghiară a fost concepută pentru a fi independentă de limbă și și-a găsit prima utilizare majoră cu limbajul de programare BCPL . Deoarece BCPL nu are alte tipuri de date decât cuvântul mașină , nimic în limbajul în sine nu ajută un programator să-și amintească tipurile de variabile. Notarea maghiară își propune să remedieze acest lucru oferind programatorului cunoștințe explicite despre tipul de date al fiecărei variabile.

În notația maghiară, un nume de variabilă începe cu un grup de litere mici care sunt mnemonice pentru tipul sau scopul acelei variabile, urmat de orice nume a ales programatorul; această ultimă parte este uneori distinsă ca nume dat . Primul caracter al numelui dat poate fi scris cu majuscule pentru al separa de indicatorii de tip (vezi și CamelCase ). În caz contrar, cazul acestui personaj denotă domeniul de aplicare.

Istorie

Notația maghiară originală, care acum s-ar numi Apps Hungarian, a fost inventată de Charles Simonyi , un programator care a lucrat la Xerox PARC în jurul anului 1972–1981 și care a devenit ulterior Arhitect șef la Microsoft .

Numele notației este o referință la națiunea de origine a lui Simonyi; Numele poporului maghiar sunt „inversate” în comparație cu majoritatea celorlalte nume europene; numele de familie precede numele dat . De exemplu, numele anglicizat „Charles Simonyi” în limba maghiară a fost inițial „Simonyi Károly”. În același mod, numele de tip precede „denumirea” în notația maghiară, mai degrabă decât stilul de denumire „ultimul” de tip Smalltalk (de exemplu, aPoint și lastPoint). Acest ultim stil de denumire a fost cel mai comun la Xerox PARC în timpul mandatului lui Simonyi acolo.

Numele Apps Hungarian a fost inventat, deoarece convenția a fost utilizată în divizia de aplicații a Microsoft. Sistemele maghiare s-au dezvoltat ulterior în echipa de dezvoltare Microsoft Windows . Lucrarea lui Simonyi se referea la prefixe utilizate pentru a indica „tipul” de informații stocate. Propunerea sa a fost preocupat în mare măsură cu decorarea nume de identificare pe baza informației semantice a ceea ce le stoca (cu alte cuvinte, variabilei scop ), în conformitate cu aplicațiile din Ungaria. Cu toate acestea, sugestiile sale nu erau în totalitate distincte de ceea ce a devenit cunoscut sub denumirea de sisteme maghiare, deoarece unele dintre prefixele sale sugerate conțin informații semantice puține sau deloc (a se vedea mai jos pentru exemple).

Sisteme Maghiară vs. Aplicații Maghiară

Acolo unde notația sistemelor și notația aplicațiilor diferă este în scopul prefixelor.

În notația maghiară de sistem, prefixul codifică tipul de date real al variabilei. De exemplu:

  • lAccountNum : variabila este un întreg lung ( "l");
  • arru8NumberList : Variabila este o arr ay de u nsigned 8 întregi -bit ( "arru8");
  • bReadLine(bPort,&arru8NumberList) : funcție cu un cod de returnare a valorii octeților.
  • strName : Variabila reprezintă un șir ( "str") care conține numele, dar nu specifică modul în care acel șir este implementat.

Aplicațiile notația maghiară se străduiește să codifice tipul de date logice mai degrabă decât tipul de date fizice; în acest fel, oferă un indiciu cu privire la care este scopul variabilei sau ce reprezintă ea.

  • rwPosition : variabila reprezintă un rând ( "rw");
  • usName : variabila reprezintă un șir nesigur ( "us"), care trebuie „igienizat” înainte de a fi utilizat (de exemplu, consultați injecția de cod și scripturile între site-uri pentru exemple de atacuri care pot fi cauzate de utilizarea intrării brute a utilizatorului)
  • szName : variabila este un z ero-terminat s tring ( "sz"); acesta a fost unul dintre prefixurile sugerate de Simonyi.

Majoritatea, dar nu toate, dintre prefixele sugerate de Simonyi sunt de natură semantică. Pentru ochii moderni, unele prefixe par să reprezinte tipuri de date fizice, cum ar fi szșirurile. Cu toate acestea, astfel de prefixe erau încă semantice, întrucât Simonyi intenționa notația maghiară pentru limbi ale căror sisteme de tip nu puteau distinge unele tipuri de date pe care limbile moderne le iau de la sine.

Următoarele sunt exemple din lucrarea originală:

  • pXeste un pointer către un alt tip X ; aceasta conține foarte puține informații semantice.
  • deste un prefix care înseamnă diferență între două valori; de exemplu, dY ar putea reprezenta o distanță de-a lungul axei Y a unui grafic, în timp ce o variabilă numită doar y ar putea fi o poziție absolută. Aceasta are o natură complet semantică.
  • szeste un șir terminat nul sau zero. În C, acesta conține unele informații semantice, deoarece nu este clar dacă o variabilă de tip char * este un pointer către un singur caracter, o matrice de caractere sau un șir terminat zero.
  • wmarchează o variabilă care este un cuvânt. Aceasta nu conține, în esență, deloc informații semantice și ar fi probabil considerată sisteme maghiare.
  • bmarchează un octet, care spre deosebire de w ar putea avea informații semantice, deoarece în C singurul tip de date de dimensiunea unui octet este char , deci acestea sunt uneori folosite pentru a păstra valori numerice. Acest prefix ar putea elimina ambiguitatea între dacă variabila deține o valoare care ar trebui tratată ca un caracter sau un număr.

Deși notația folosește întotdeauna litere minuscule inițiale ca mnemonică, nu prescrie mnemonica însăși. Există mai multe convenții utilizate pe scară largă (a se vedea exemplele de mai jos), dar orice set de litere poate fi utilizat, atâta timp cât acestea sunt consistente într-un corp dat de cod.

Este posibil ca codul care utilizează notația în limba maghiară să conțină uneori sisteme în limba maghiară atunci când descrie variabile care sunt definite numai în funcție de tipul lor.

Relația cu sigilii

În unele limbaje de programare, o notație similară numită acum sigils este încorporată în limbaj și impusă de compilator. De exemplu, în unele forme de BASIC , name$numește un șir și count%numește un număr întreg . Diferența majoră dintre notația maghiară și sigilii este că sigilele declară tipul variabilei în limbă, în timp ce notația maghiară este pur o schemă de denumire fără niciun efect asupra interpretării automate a textului programului.

Exemple

  • bBusy : boolean
  • chInitial : char
  • cApples : număr de articole
  • dwLightYears : cuvânt dublu (Sisteme)
  • fBusy : pavilion (sau plutitor )
  • nSize : număr întreg (Sisteme) sau numărare (Aplicații)
  • iSize : întreg (sisteme) sau index (aplicații)
  • fpPrice : virgulă mobilă
  • dbPi : dublu (Sisteme)
  • pFoo : pointer
  • rgStudents : matrice sau interval
  • szLastName : șir terminat zero
  • u16Identifier : Unsigned 16 biți întreg (Systems)
  • u32Identifier : Unsigned 32-bit întreg (Systems)
  • stTime : structura orei ceasului
  • fnFunction : numele funcției

Mnemonica pentru indicatori și tablouri , care nu sunt tipuri de date efective, este de obicei urmată de tipul elementului de date în sine:

  • pszOwner : pointer către șirul terminat cu zero
  • rgfpBalances : matrice de valori în virgulă mobilă
  • aulColors : matrice de nesemnate lungi (Sisteme)

Deși notația maghiară poate fi aplicată oricărui limbaj și mediu de programare, a fost adoptată pe scară largă de Microsoft pentru utilizarea cu limbajul C, în special pentru Microsoft Windows , iar utilizarea sa rămâne în mare parte limitată la acea zonă. În special, utilizarea notație maghiar a fost pe larg evanghelizată de Charles Petzold „s «Programarea Windows» , original (și pentru mulți cititori, definitiv) , cartea pe API Windows de programare. Astfel, multe construcții frecvent observate ale notației maghiare sunt specifice Windows:

  • Pentru programatorii care au învățat programarea Windows în C, probabil cele mai memorabile exemple sunt wParam(parametrul dimensiunea cuvântului) și lParam(parametrul întregului lung) pentru funcția WindowProc ().
  • hwndFoo : mâner la o fereastră
  • lpszBar : indicator lung către un șir terminat zero

Notarea este uneori extinsă în C ++ pentru a include domeniul de aplicare al unei variabile, opțional separate printr-o subliniere. Această extensie este adesea utilizată și fără specificațiile de tip maghiare:

  • g_nWheels : membru al unui spațiu de nume global, întreg
  • m_nWheels : membru al unei structuri / clase, întreg
  • m_wheels, _wheels : membru al unei structuri / clase
  • s_wheels : membru static al unei clase
  • c_wheels : membru static al unei funcții

În codul JavaScript care utilizează jQuery , un $prefix este adesea folosit pentru a indica faptul că o variabilă deține un obiect jQuery (față de un obiect DOM simplu sau o altă valoare).

Avantaje

(Unele dintre acestea se aplică numai sistemelor maghiare.)

Susținătorii susțin că beneficiile notației maghiare includ:

  • Tipul simbolului poate fi văzut din numele său. Acest lucru este util atunci când priviți codul în afara unui mediu de dezvoltare integrat - cum ar fi o revizuire a codului sau o imprimare - sau când declarația simbolului se află într-un alt fișier din punctul de utilizare, cum ar fi o funcție.
  • Într-un limbaj care folosește tastarea dinamică sau care nu este tipat, decorațiunile care se referă la tipuri încetează să mai fie redundante. În astfel de limbi, variabilele nu sunt de obicei declarate ca deținând un anumit tip de date, astfel încât singurul indiciu cu privire la ce operațiuni se pot face pe acesta sunt indicii date de programator, cum ar fi o schemă de denumire a variabilelor, documentație și comentarii. După cum sa menționat mai sus, notația maghiară sa extins într-o astfel de limbă ( BCPL ).
  • Formatarea numelor variabilelor poate simplifica unele aspecte ale refactorizării codului (făcând în același timp alte aspecte mai predispuse la erori).
  • Mai multe variabile cu semantică similară pot fi utilizate într-un bloc de cod: dwWidth, iWidth, fWidth, dWidth.
  • Numele variabilelor pot fi ușor de reținut din a cunoaște doar tipurile lor.
  • Aceasta duce la nume de variabile mai consistente.
  • Distribuirea de tip inadecvat și operațiile care utilizează tipuri incompatibile pot fi detectate cu ușurință în timpul citirii codului.
  • În programele complexe cu multe obiecte globale (VB / Delphi Forms), având o notație de bază cu prefix poate ușura activitatea de a găsi componenta din editor. De exemplu, căutarea șirului btnar putea găsi toate obiectele Buton.
  • Aplicarea notației maghiare într-un mod mai restrâns, cum ar fi aplicarea numai pentru variabilele membre , ajută la evitarea coliziunii de denumire .
  • Codul tipărit este mai clar pentru cititor în cazul tipurilor de date, conversiilor de tipuri, alocărilor, trunchierilor etc.

Dezavantaje

Cele mai multe argumente împotriva notării maghiare sunt împotriva notării maghiare în sisteme , nu notației maghiare în aplicații . Unele probleme potențiale sunt:

  • Notarea maghiară este redundantă atunci când verificarea de tip este efectuată de compilator. Compilatoarele pentru limbi care asigură verificarea strictă a tipului, cum ar fi Pascal , asigură utilizarea unei variabile în concordanță cu tipul acesteia în mod automat; verificările oculare sunt redundante și sunt supuse unor erori umane.
  • Majoritatea mediilor moderne de dezvoltare integrată afișează tipuri variabile la cerere și semnalează automat operațiunile care utilizează tipuri incompatibile, făcând notația în mare parte învechită.
  • Notarea maghiară devine confuză atunci când este utilizată pentru a reprezenta mai multe proprietăți, ca în a_crszkvc30LastNameCol: un argument de referință constantă , care conține conținutul unei coloane de baze de date de tip varchar (30) care face parte din cheia primară a tabelului . LastName
  • Poate duce la incoerență atunci când codul este modificat sau portat. Dacă tipul unei variabile este modificat, fie decorația de pe numele variabilei va fi incompatibilă cu noul tip, fie numele variabilei trebuie schimbat. Un exemplu deosebit de cunoscut este tipul WPARAM standard și parametrul formal wParam însoțitor în multe declarații de funcții de sistem Windows. „W” înseamnă „cuvânt”, unde „cuvânt” este dimensiunea cuvântului nativ al arhitecturii hardware a platformei. Acesta a fost inițial un tip de 16 biți pe arhitecturi de cuvinte de 16 biți, dar a fost schimbat în 32 de biți pe arhitecturi de cuvinte pe 32 de biți sau tip de 64 de biți pe arhitecturi de cuvinte pe 64 de biți în versiunile ulterioare ale sistemului de operare, păstrând în același timp numele original (adevăratul său tip de bază este UINT_PTR, adică un număr întreg nesemnat suficient de mare pentru a ține un indicator). Impedanța semantică și, prin urmare, confuzia și inconsecvența programatorului de la platformă la platformă, se presupune că „w” reprezintă un cuvânt de doi octeți pe 16 biți în acele medii diferite.
  • De cele mai multe ori, cunoașterea utilizării unei variabile implică cunoașterea tipului acesteia. Mai mult, dacă utilizarea unei variabile nu este cunoscută, nu poate fi dedusă din tipul ei.
  • Notarea maghiară reduce avantajele utilizării editorilor de cod care acceptă finalizarea pe numele variabilelor, deoarece programatorul trebuie să introducă mai întâi specificatorul de tip, care este mai probabil să se ciocnească cu alte variabile decât atunci când se utilizează alte scheme de denumire.
  • Face codul mai puțin lizibil, prin ascunderea scopului variabilei cu prefixe de tip și scop.
  • Informațiile suplimentare de tip pot înlocui insuficient denumiri mai descriptive. De exemplu, sDatabase nu spune cititorului ce este. databaseName ar putea fi un nume mai descriptiv.
  • Când numele sunt suficient de descriptive, informațiile suplimentare despre tip pot fi redundante. De exemplu, prenumele este cel mai probabil un șir. Așadar, denumirea sFirstName adaugă doar dezordine la cod.
  • Este mai greu să-ți amintești numele.
  • Mai multe variabile cu semantică diferită pot fi utilizate într-un bloc de cod cu nume similare: dwTmp, iTmp, fTmp, dTmp .
  • Plasarea tipurilor de date sau a identificatorilor de caractere de intenție ca prefix la numele de câmp sau variabilă subversează capacitatea, în unele medii de programare, de a trece la un câmp sau la o variabilă, alfabetic, atunci când utilizatorul începe să tasteze numele. FileMaker, de exemplu, este un astfel de mediu de programare. Poate fi preferabil atunci când se utilizează unul dintre aceste medii de programare să se sufixeze în schimb numele date cu astfel de caractere de identificare.

Opinii notabile

  • Robert Cecil Martin (împotriva notării maghiare și a tuturor celorlalte forme de codificare):

    ... în zilele noastre HN și alte forme de codificare de tip sunt pur și simplu impedimente. Acestea fac mai dificilă schimbarea numelui sau tipului unei variabile, a unei funcții, a unui membru sau a unei clase. Îngreunează citirea codului. Și creează posibilitatea ca sistemul de codificare să inducă în eroare cititorul.

  • Linus Torvalds (împotriva sistemelor maghiare):

    Codificarea tipului unei funcții în nume (așa-numita notație maghiară) este afectată de creier - compilatorul știe oricum tipurile și le poate verifica și confundă doar programatorul.

  • Steve McConnell (pentru aplicațiile maghiare):

    Deși convenția de denumire maghiară nu mai este utilizată pe scară largă, ideea de bază a standardizării pe scurt, abrevieri precise continuă să aibă valoare. Prefixele standardizate vă permit să verificați cu precizie tipurile atunci când utilizați tipuri de date abstracte pe care compilatorul dvs. nu le poate verifica în mod necesar.

  • Bjarne Stroustrup (împotriva sistemelor maghiare pentru C ++):

    Nu, nu recomand „maghiară”. Consider „maghiară” (încorporarea unei versiuni prescurtate a unui tip într-un nume variabil) ca o tehnică care poate fi utilă în limbaje netipate, dar este complet nepotrivită pentru un limbaj care acceptă programarea generică și programarea orientată pe obiecte - ambele subliniind selectarea operațiunilor pe baza tipului și argumentelor (cunoscute de limbă sau de suportul de execuție). În acest caz, „construirea tipului de obiect în nume” complică și minimizează abstractizarea.

  • Joel Spolsky (pentru aplicații maghiare):

    Dacă citiți îndeaproape lucrarea lui Simonyi, la ce se ocupa el a fost același tip de convenție de numire pe care am folosit-o în exemplul meu de mai sus, unde am decis că asta usînseamnă șir nesigur și sînseamnă șir sigur. Amândoi sunt de tip string. Compilatorul nu vă va ajuta dacă îi atribuiți unul celuilalt și Intellisense [un sistem inteligent de completare a codului ] nu vă va spune bupkis . Dar ele sunt semantic diferite. Acestea trebuie interpretate diferit și tratate diferit și va trebui apelat un fel de funcție de conversie dacă le atribuiți uneia celeilalte sau veți avea o eroare de execuție. Dacă ești norocos. Există încă o valoare extraordinară pentru Apps Maghiară, prin faptul că crește colocarea în cod, ceea ce face codul mai ușor de citit, scris, depanat și întreținut și, cel mai important, face ca codul greșit să arate greșit ... (Sisteme Maghiară) a fost o subtilă, dar completă neînțelegere a intenției și practicii lui Simonyi.

  • Liniile directoare de proiectare ale Microsoft descurajează dezvoltatorii să utilizeze notarea în sistem maghiar atunci când aleg nume pentru elementele din bibliotecile de clase .NET, deși era obișnuit pe platformele de dezvoltare Microsoft anterioare precum Visual Basic 6 și versiuni anterioare. Aceste Linii directoare de proiectare nu conțin informații despre convențiile de denumire pentru variabilele locale din cadrul funcțiilor.

Vezi si

Referințe

linkuri externe