A programozásban az elnevezési konvenció az azonosítók elnevezésére vonatkozó szabályok összessége, amelyek változókat , típusokat , függvényeket és egyéb dolgokat reprezentálnak a forráskódban és a dokumentációban .
A konvenciók tetszőleges nevek helyett a következő feladatok végrehajtására használhatók:
Az elnevezési konvenciók megválasztása rendkívül vitatott kérdés lehet, mivel mindegyik hívei saját konvenciójukat látják a legjobbnak, mások pedig a legrosszabbnak. A köznyelvben az ilyen megbeszéléseket "holivaroknak" nevezik (az angol holy war - holy war szóból ) [2] . Sok cég köt saját megállapodást [3] [4] [5] [6] [7] [8] .
Az elnevezési konvenció elfogadásával elérhető lehetséges előnyök közül néhány:
Az elnevezési konvenciók megválasztása (és azok betartatásának mértéke) gyakran vitatott kérdés, mivel a támogatók a legjobbak, mások pedig a legrosszabb álláspontjukhoz ragaszkodnak. Sőt, még ha vannak is jól ismert és jól meghatározott elnevezési konvenciók, előfordulhat, hogy egyes szervezetek nem tartják be azokat következetesen, ami következetlenségekhez és zavarokhoz vezet. Ezek a problémák súlyosbodhatnak, ha az elnevezési szabályok belsőleg inkonzisztensek, önkényesek, nehezen megjegyezhetőek, vagy más módon inkább megterhelőnek, mint hasznosnak tartják.
A jól megválasztott azonosítók megkönnyítik a fejlesztők és elemzők számára, hogy megértsék, mit csinál a rendszer, és hogyan lehet javítani vagy kiterjeszteni a forráskódot az új igényekhez való alkalmazkodás érdekében.
Például bár
a = b*c;szintaktikailag helyes, célja nem nyilvánvaló. Hasonlítsa össze ezt:
heti_fizetés = ledolgozott_órák * órabér;ami a forráskód megértését jelenti, legalábbis azok számára, akik ismerik az állítás kontextusát.
Az elnevezési konvenciók pontos szabályai attól függnek, hogy milyen környezetben használják őket. Van azonban néhány közös elem, amely befolyásolja a legtöbb, ha nem az összes elnevezési konvenciót, amelyet ma általánosan használnak.
Az összes elnevezési konvenció alapelemei az azonosító hosszára vonatkozó szabályok (vagyis az azonosítóban megengedett különbözõ karakterek véges számával). Egyes szabályok rögzített számszerű korlátot írnak elő, míg mások kevésbé pontos értékeket vagy iránymutatásokat adnak meg.
Az azonosító hosszára vonatkozó szabályokat a gyakorlatban gyakran vitatják, és sok tudományos vita tárgyát képezik.
Néhány szempont:
Nyitott kutatási kérdés, hogy egyes programozók előnyben részesítik-e a rövidebb azonosítókat, mert azokat könnyebb begépelni vagy kitalálni, mint a hosszabb azonosítókat, vagy pedig azért, mert sok esetben egy hosszabb azonosító egyszerűen összezavarja a látható kódot, és semmilyen látható többletelőnnyel nem jár.
A programozás rövidsége részben a következőkkel magyarázható:
Egyes elnevezési konvenciók korlátozzák a betűk kis- és nagybetűs megjelenítését. Más konvenciók nem korlátozzák a kis- és nagybetűket, hanem jól körülhatárolható értelmezést adnak a kis- és nagybetűk alapján. Egyes elnevezési konvenciók meghatározzák, hogy alfabetikus, numerikus vagy alfanumerikus karakterek használhatók-e, és ha igen, milyen sorrendben.
Az általános ajánlás a következő: „Használjon értelmes azonosítókat”. Lehet, hogy egy szó nem olyan értelmes vagy specifikus, mint több szó. Ezért egyes elnevezési konvenciók szabályokat határoznak meg az egynél több szót tartalmazó „összetett” azonosítók kezelésére.
Mivel a legtöbb programozási nyelv nem engedélyezi a szóközt az azonosítókban, szükség van egy módszerre az egyes szavak elválasztására (hogy a későbbi olvasók könnyebben értelmezzék, melyik karakter melyik szóhoz tartozik). Történelmileg néhány korai nyelv, nevezetesen a FORTRAN (1955) és az ALGOL (1958), szóközt engedett meg az azonosítókban azáltal, hogy kontextus szerint határozta meg az azonosítók végét. Ezt a későbbi nyelvekben a tokenizálás nehézségei miatt elhagyták . Lehetőség van nevek írására a szavak egyszerű összefűzésével, és ezt néha használják is, mint például a mypackageJava csomagnevekben [9] , bár az olvashatóság a hosszabb kifejezéseknél szenved, ezért általában valamilyen elválasztási formát alkalmaznak.
Határolójelekkel elválasztott szavakAz egyik megközelítés az egyes szavak elválasztása nem alfanumerikus karakterekkel. Általában két karaktert használnak erre a célra: egy kötőjelet ("-") és egy aláhúzást ("_"); például egy kétszavas név vagy «two words»jelölést kaphat . A kötőjelet szinte minden COBOL (1959), Forth (1970) és Lisp (1958) programozó használja; a Unixban is gyakori a parancsok és csomagok esetében, és a CSS -ben is használatos [10] . Ennek az egyezménynek nincs szabványos neve, bár nevezhetjük lisp-case- nek vagy COBOL-CASE- nek (vö . Pascal-tok ), kebab-tok , brochette-tok vagy más változatok [11] [12] [13] [14] . Ezek közül a legalább 2012-ből származó kebab [15] azóta népszerűvé vált [16] [17] . «two-words»«two_words»
Ezzel szemben a FORTRAN/ALGOL-hagyomány nyelvei, különösen a C és a Pascal családok , a kötőjelet használták az infix kivonás operátoraként , és nem akartak szóközt előírni körülötte (mint a szabad formájú nyelvek), megakadályozva ezzel használata azonosítókban. Egy másik lehetőség az aláhúzás használata; ez gyakori a C családban (beleértve a Pythont is), ahol kisbetűs szavak fordulnak elő, mint például a C programozási nyelvben (1978), és kígyó esetként vált ismertté . A nagybetűs aláhúzásjelek, akárcsak a UPPER_CASE, általában a C előfeldolgozó makrókhoz használatosak , ezért MACRO_CASE néven ismertek, és a Unix környezeti változókhoz , például a BASH_VERSION a bash -ban . Ezt néha humorosan SCREAMING_SNAKE_CASE-nek nevezik.
Betűkkel elválasztott szavakEgy másik megközelítés a szóhatárok jelzése a " camelCase ", "Pascal case" és sok más néven nevezett középső nagybetűkkel, így jelenítve meg , vagy . Ezt a konvenciót általában a Pascal , Java , C# és Visual Basic nyelvekben használják . Az azonosítókban lévő inicializmusok kezelése (például " XML " és " HTTP " in ) változó. Egyesek úgy érzik, hogy kisbetűvel (pl . ) kell írni a könnyebb gépelés és olvashatóság érdekében, míg mások nagybetűvel (pl. ) hagyják őket a pontosság érdekében. «two words»«twoWords»«TwoWords»XMLHttpRequestXmlHttpRequestXMLHTTPRequest
Példák bőbeszédű azonosító formátumokra| Formátum | Név |
|---|---|
| twowords | lapos tok [18] [19] |
| TWOWORDS | felső lapos tok [18] |
| twoWords | (alsó) camelCase , dromedaryCase |
| TwoWords | (felső) CamelCase , PascalCase, StudlyCase [20] |
| two_words | kígyótok , kátyútok |
| TWO_WORDS | Screaming SNAKE CASE , MACRO_CASE, CONSTANT_CASE |
| Two_Words | Camel_Snake_ Case [21] |
| two-words | kebabtartó , kötőjeles tok , lisp tok |
| TWO-WORDS | VONAT-TOK, COBOL-TOK, ÜVÍTŐ-KEBAB-TOK |
| Two-Words | Train-Case, [18] HTTP-Header-Case [21] |
Egyes elnevezési konvenciók olyan szabályok vagy követelmények, amelyek túlmutatnak egy adott projekt vagy tartomány követelményein, és ehelyett a szoftverarchitektúra , az alapul szolgáló programozási nyelv vagy más projektközi módszertan által meghatározott elvek szélesebb körét tükrözik.
Talán a legismertebb a magyar jelölés , amely vagy egy változó célját ("Apps Hungarian"), vagy típusát ("Systems Hungarian") kódolja a nevében [22] . Például az szName változó "sz" előtagja azt jelzi, hogy a változó egy null-végződésű karakterlánc.
A nagyon rövid (nyolc vagy kevesebb karakter) kifejezéshez használt stílus a következő lehet: LCCIIL01, ahol az LC a csatolmány (akkreditív), a C a COBOL, az IIL a folyamatok egy meghatározott részhalmaza, a 01 pedig egy sorszám.
Ezt a konvenciót még mindig aktívan használják a JCL-től függő nagyszámítógépekben, és megtalálható az MS-DOS 8.3 stílusban is (maximum nyolc karakterből állhat egy elválasztó pont és egy három karakteres fájltípus).
Az IBM "OF Language"-jét az IMS ( Információkezelő rendszer ) kézikönyv dokumentálta.
Részletezi a PRIME-MODIFIER-CLASS szósémát, amely olyan nevekből áll, mint például a "CUST-ACT-NO" az "ügyfélszámlaszám" helyett.
A PRIME szavak célja a rendszer számára érdekes fő "entitások" jelölése volt.
A MÓDOSÍTÓ szavakat a pontosítás, finomítás és olvashatóság érdekében használták.
Ideális esetben az OSZTÁLY szavak nagyon rövid listája az alkalmazás-specifikus adattípusoknak. A gyakori CLASS szavak lehetnek: NO (szám), ID (azonosító), TXT (szöveg), AMT (összeg), QTY (mennyiség), FL (zászló), CD (kód), W (munka), stb. , a rendelkezésre álló OSZTÁLY szavak egy két tucatnál kevesebb kifejezésből álló lista lesz.
Az OSZTÁLY szavak, amelyeket általában jobbra (utótag) helyeznek el, szinte ugyanazt a célt szolgálják, mint a magyar jelölési előtagok .
Az OSZTÁLY szavak célja a következetességen túl az volt, hogy a programozó felé jelezzék egy adott adatmező adattípusát . A BOOLEAN (csak két érték) mezők elfogadása előtt az FL (jelző) egy olyan mezőre mutat, amelynek csak két lehetséges értéke van.
Az Adobe Coding Conventions and Best Practices olyan elnevezési szabványokat biztosít az ActionScript számára , amelyek többnyire követik az ECMAScript szabványokat . Az azonosítók stílusa hasonló a Java stílusához .
Adában az egyetlen ajánlott stílus az azonosítókhoz a [ Mixed_Case_With_Underscores23] .
Az APL nyelvjárások deltát (Δ) használnak a szavak között, mint például a PERFΔSQUARE (az APL régebbi verzióiban hagyományosan nem voltak kisbetűk). Ha aláhúzott betűket használ a névben, a rendszer egy aláhúzott delta kötőjelet (⍙) használ helyette.
C és C++ nyelven a szabványos könyvtári kulcsszavak és azonosítók többnyire kisbetűvel íródnak. A C szabványos könyvtárban a rövidítések a leggyakoribbak (például egy olyan függvénynél, amely ellenőrzi, hogy egy karakter alfanumerikus-e), míg a C++ szabványos könyvtár gyakran használ aláhúzást szóelválasztóként (például ). A makrókat képviselő azonosítók hagyományosan csak nagybetűkkel és aláhúzásjelekkel vannak írva (ez annak köszönhető, hogy sok programozási nyelvben az a konvenció, hogy az állandókhoz csak nagybetűs azonosítókat használnak). A dupla aláhúzást tartalmazó vagy aláhúzással és nagybetűvel kezdődő nevek a megvalósítás számára vannak fenntartva ( fordító , szabványos könyvtár ), és nem használhatók (pl. vagy ) [24] [25] . Ez felületesen hasonlít a slingingre, de a szemantika más: az aláhúzás az azonosító értékének része, nem pedig a karakterek idézőjel (mint például a slinging): az érték ( amely le van foglalva) nem (hanem egy másik névtérben). isalnumout_of_range__reserved_Reserved__foo__foofoo
A C# elnevezési konvenciók általában követik a Microsoft által az összes NET-nyelvre vonatkozóan közzétett ajánlásokat [26] (lásd a NET-et alább), de a C# fordító semmilyen konvenciót nem kényszerít ki.
A Microsoft kézikönyve kizárólag a PascalCase és a CamelCase használatát javasolja , ez utóbbit csak a paraméternevekhez és a helyi (beleértve a metódus local const) értékek metódusváltozónevéhez használják. A PascalCase esetében különleges kivételt képeznek a kétbetűs betűszavak, amelyek egy azonosítót kezdenek; ezekben az esetekben mindkét betű IOStreambetű (például IOStream); ez nem vonatkozik a hosszabb betűszavakra (pl XmlStream. ). A kézikönyv azt is javasolja, hogy a megadott név PascalCaseinterface legyen , amelyet egy nagy I -es betű előz meg , mint a . IEnumerable
A Microsoft mezőelnevezési irányelvei a staticés publicmezőkre protectedvonatkoznak; azokra a mezőkre, amelyek nem staticés más hozzáférhetőségi szintekkel rendelkeznek (például internalés private), nyilvánvalóan nem vonatkoznak a [27] irányelvek . A legelterjedtebb gyakorlat az, hogy minden mezőnévhez PascalCase -t használunk , kivéve azokat, amelyek private(és nem is const, sem static), amelyek olyan nevek, amelyek a camelCase -t egyetlen aláhúzás előtt használják; például, _totalCount.
Bármely azonosító név kezdődhet idézőjel karakterrel ( @ ), a jelentés megváltoztatása nélkül. Vagyis és factor, és @factorugyanarra az objektumra hivatkoznak. Megállapodás szerint ez az előtag csak akkor használatos, ha az azonosító egyébként vagy fenntartott kulcsszó (például forés while), amely nem használható előtag nélküli azonosítóként, vagy kontextusfüggő kulcsszó (például fromés where), ebben az esetben a az előtag nem kötelező (legalábbis deklaráláskor nem; például bár a deklaráció dynamic dynamic;érvényes, általában azt látják, dynamic @dynamic;hogy azonnal jelzi az olvasónak, hogy az utóbbi egy változónév).
A Go -ban a bőbeszédű neveket szokás használni MixedCapsvagy mixedCapsaláhúzás helyett. Ha osztályokra vagy függvényekre hivatkozunk, az első betű a külső csomagok láthatóságát jelzi. Ha az első betűt nagybetűvé teszi, akkor ez a kódrészlet exportálásra kerül, míg a kisbetűk csak az aktuális hatókörben [28] .
A Java nyelven az azonosítók elnevezési konvencióit különféle Java közösségek fejlesztették ki és javasolták, például a Sun Microsystems [29] , a Netscape [30] , az AmbySoft [31] stb. A név a " CamelCase "-ban több szóból áll, amelyek szóközök nélkül vannak összefűzve, minden szó kezdő nagybetűjével , például "CamelCase".
| Azonosító típusa | Elnevezési szabályok | Példák |
|---|---|---|
| osztályok | Az osztályneveknek főneveknek kell lenniük , minden szó első betűjét nagybetűvel kell írni. Használjon egész szavakat – kerülje a mozaikszavakat és rövidítéseket (kivéve, ha a rövidítést sokkal szélesebb körben használják, mint a hosszú formát, például URL vagy HTML). Upper CamelCase |
|
| Mód | A módszereknek kisbetűs igéknek vagy többszavas neveknek kell lenniük , amelyek kisbetűs igével kezdődnek; vagyis az első betűt kisbetűvel és a következő szavak első betűit nagybetűvel. lower CamelCaselower CamelCase |
|
| Változók | A helyi változók, a példányváltozók és az osztályváltozók szintén a -ba íródnak . A változónevek nem kezdődhetnek aláhúzással ( ) vagy dollárjellel ( ), még akkor sem, ha mindkettő engedélyezett. Ez ellentétben áll más kódolási konvenciókkal, amelyek kimondják, hogy minden példányváltozót aláhúzásjelekkel kell ellátni.
lower CamelCase_$ A változóneveknek rövidnek, de értelmesnek kell lenniük. A változónév megválasztásának emlékeztetőnek kell lennie, vagyis a véletlen szemlélőnek jeleznie kell a használat célját. Az egykarakteres változóneveket kerülni kell, az ideiglenes „egyszeri” változók kivételével. Általános ideiglenes változónevek: i, j, k, m és n egész számokhoz; c, d és e karakterekhez. |
|
| Állandók | A konstansokat nagybetűvel kell írni, aláhúzással elválasztva. Az állandó nevek szükség esetén számokat is tartalmazhatnak, de nem első karakterként. |
|
A Java fordítók nem kényszerítik ki ezeket a szabályokat, de be nem tartásuk zavart és hibás kódot eredményezhet. Például, widget.expand()és Widget.expand()lényegesen eltérő viselkedést jelent: widget.expand()metódushívást jelent a nevű expand()példányon widget, míg Widget.expand()statikus metódushívást. expand()osztályban Widget.
Az egyik széles körben használt Java kódolási stílus megköveteli , hogy az osztályokhoz az UpperCamelCase -t, a példányokhoz és metódusokhoz pedig a LowCamelCase -t kell használni [29] . Felismerve ezt a használatot, egyes IDE -k , például az Eclipse , a CamelCase-en alapuló parancsikonokat valósítanak meg. Például az Eclipse tartalomsegéd funkciójában a CamelCase szó csupa nagybetűvel történő beírása bármilyen megfelelő osztály- vagy metódusnevet javasol (például az „NPE” beírása és a tartalomsegéd aktiválása javasolhatja a ). NullPointerException
Három vagy több betű kezdőbetűi – CamelCase nagybetű helyett (például parseDbmXmlFromIPAddress) parseDBMXMLFromIPAddress. Két vagy több betűből álló szegélyt is beállíthat (például parseDbmXmlFromIpAddress).
A beépített JavaScript-könyvtárak ugyanazokat az elnevezési konvenciókat használják, mint a Java. Az adattípusok és a konstruktor függvények nagybetűket ( RegExp , TypeError , XMLHttpRequest , DOMObject ), a metódusok pedig kisbetűket ( getElementById , getElementsByTagNameNS , createCDATASection ) használnak. A következetesség érdekében a legtöbb JavaScript-fejlesztő követi ezeket az egyezményeket [32] [33] .
A legtöbb Lisp dialektusban bevett gyakorlat az , hogy kötőjeleket használnak a szavak elválasztására az azonosítókban, például a with-open-fileés make-hash-table. A dinamikus változónevek általában csillaggal kezdődnek és végződnek: *map-walls*. Az állandó neveket pluszjellel jelöljük: +map-size+[34] [35] .
A Microsoft .NET a PascalCase néven is ismert UpperCamelCase -t ajánlja a legtöbb azonosítóhoz. A paraméterek és a változók esetében ajánlatos a LowCamelCase ) használata, amely a .NET nyelvek általános konvenciója [36] . A Microsoft azt is javasolja, hogy ne használjunk típuselőtag-utalásokat (más néven magyar jelölés [37] . A magyar jelölés használata helyett javasoljuk, hogy a nevet az alaposztálynévvel zárja le: [38]LoginButton helyett . BtnLogin
Az Objective-C általános programozási stílusa a Smalltalk - ban gyökerezik .
A legfelső szintű entitások, beleértve az osztályokat, protokollokat, kategóriákat, valamint az Objective-C programokban használt C-konstrukciókat, például a globális változókat és függvényeket, UpperCamelCase-ben vannak egy rövid nagybetűs előtaggal, amely a névteret jelöli, például NSString , UIAppDelegate . NSApp vagy CGRectMake . A konstansok előtagjaként tetszőlegesen kisbetűs "k" is szerepelhet, például a kCFBooleanTrue .
Az objektumváltozók a LowCamelCase-t használják aláhúzással, például a _delegate és a _tableView .
A metódusnevek több kettősponttal elválasztott alsó CamelCase részt használnak, amelyek elválasztják az argumentumokat, például: application: didFinishLaunchingWithOptions: , stringWithFormat: és isRunning .
A Pascal, a Modula-2 és az Oberon nyelvek általában azonosítókat Capitalizedvagy UpperCamelCaseprogramokhoz, modulokhoz, konstansokhoz, típusokhoz és eljárásokhoz és lowerCamelCaseazonosítókhoz lowercasevagy lowerCamelCasematematikai konstansokhoz, változókhoz, formális paraméterekhez és függvényekhez használnak [39] . Míg egyes dialektusok támogatják az aláhúzást és a dollárjeleket az azonosítókban, a kígyó- és a makró-betűk használata valószínűleg csak a külső API-kban használható [40] .
A Perl néhány szabályt a C örökségéből vesz át, a változók és a helyi hatókörű alprogramnevek kisbetűkkel és aláhúzásjelekkel vannak írva. A privátként kezelendő szubrutinok és változók előtt aláhúzás van. A csomagváltozók fejlécbe vannak zárva. Minden deklarált állandó nagybetűvel van írva. A csomagneveket nagybetűvel írjuk, kivéve az olyan pragmákat, mint a strictés mro, amelyeket kisbetűvel mroírunk [41] [42] .
A PHP ajánlásait a PSR-1 (PHP standard ajánlás 1) és a PSR-12 tartalmazza [43] . A PSR-1 szerint az osztályneveknek PascalCase-ben, az osztálykonstansoknak MACRO_CASE-ben, a metódusneveknek camelCase-ben [44] kell lenniük .
A Python és a Ruby használata ajánlott UpperCamelCaseosztálynevekhez, CAPITALIZED_WITH_UNDERSCORESkonstansokhoz és lowercase_separated_by_underscoresegyéb nevekhöz.
A Pythonban, ha egy név " privát " legyen egy modulon belül, ajánlatos egyetlen aláhúzással kezdeni. A nevek egy aláhúzással is végződhetnek a Python kulcsszavakkal való ütközés elkerülése érdekében. A dupla aláhúzás előtag viszont torzítja az osztálytagnevek külső megjelenítését: például egy osztályban az osztályon kívüli FooBarmetódus __booként lesz látható _FooBar__boo. A dupla aláhúzással kezdődő és végződő nevek a Pythonban különleges szerepet játszó „varázsnevek” számára vannak fenntartva (pl. __init__, __import__, __file__) [45] .
Bár az R számára nincs hivatalos stíluskalauz , Hadley Wickham R guru tidyverse stíluskalauza állítja fel a mércét a legtöbb felhasználó számára [46] . Ez az útmutató azt javasolja, hogy kerülje a speciális karaktereket a fájlnevekben, és csak számokat, betűket és aláhúzásjeleket használjon változó- és függvénynevekben, például fit_models. R.
A Raku többé-kevésbé ugyanazokat a szabályokat követi, mint a Perl, kivéve, hogy a Raku engedélyezi a belső kötőjeleket és aposztrófokat (egyszeres idézőjeleket), amíg azokat mindig betűk követik. Így a kebab -case használható Rakuban : például fish-foodés don't-do-thatérvényes azonosítók [47] .
A Rust a struct, trait, enum és enum használatát ajánlja UpperCamelCasetípusálnevekhez és változatnevekhez, SCREAMING_SNAKE_CASEkonstansokhoz vagy statikus változókhoz, valamint snake_caseváltozó-, függvény- és struktúranevekhez [48] .
A Swift minden egyes kiadással megváltoztatja elnevezési konvencióit. A Swift 3.0 fő frissítése azonban stabilizálta a lowerCamelCaseváltozók és függvénydeklarációk elnevezési konvencióit. A konstansokat általában felsorolt típusok vagy konstans paraméterek határozzák meg, amelyeket szintén ugyanúgy írnak. Az osztályok és más típusú objektumok deklarációi a UpperCamelCase.
A Swift 3.0 óta egyértelmű elnevezési irányelveket fogalmaztak meg a nyelvre vonatkozóan azzal a céllal, hogy szabványosítsák az elnevezési konvenciókat és az API-deklarációkat minden harmadik fél API-jára [49] .