Elnevezési konvenciók (programozás)

A Wikipédiából, a szabad enciklopédiából

A számítógépes programozásban az elnevezési konvenció olyan szabálykészlet, amely meghatározza a karakterek sorozatát az azonosítókhoz, amelyek a forráskódban és a dokumentációban a változókat, típusokat, függvényeket és egyéb entitásokat jelölik.

Az elnevezési konvenció alkalmazásának okai (annak ellenére, hogy a programozók bármilyen karaktersorozatot választhatnak) a következők:

  • A forráskód olvasásához és megértéséhez szükséges erőfeszítések csökkentése;[1]
  • Annak lehetővé tétele, hogy a kód áttekintésénél a résztvevők fontosabb kérdésekre összpontosíthassanak, mint a szintaxison és az elnevezéseken való vitatkozás.
  • Annak lehetővé tétele, hogy a kódminőség-ellenőrző eszközök jelentéseit elsősorban a szintaxison és a stíluspreferenciákon kívüli jelentősebb problémákra összpontosítsák.

Az elnevezési konvenciók megválasztásának kérdése felettébb vitatható lehet, amikor mindegyik résztvevő a sajátját tartja a legjobbnak, a többiekét pedig csak mellékesnek. Számos vállalat is létrehozta a saját elnevezési konvencióinak gyűjteményét.

Lehetséges előnyök[szerkesztés]

Az elnevezési konvenciók elfogadásával elérhető potenciális előnyök közé tartoznak a következők:

  • további információk (azaz metaadatok) biztosítása az azonosító felhasználásáról;
  • elősegíti az elvárások formalizálását, valamint a következetességet egy fejlesztői csoporton belül;
  • lehetővé teszi az automatikus refaktorálás vagy keresés használatát és az eszközök cseréjét, minimális hibapotenciállal;
  • egyértelművé teszi a félreérthető eseteket;
  • a munkatermék esztétikai és professzionális megjelenésének javítása (például a túlságosan hosszú nevek, képregényes vagy "aranyos" nevek vagy rövidítések tiltásával);
  • a különböző szervezetek munkatermékeinek kombinálásakor esetlegesen előforduló "elnevezési ütközések" elkerülése (lásd még: névterek);
  • jelentőségteljes adatot biztosít a projekt átadásokban való felhasználásához, amelyek igénylik a program forráskódjának és a releváns dokumentációjának a benyújtását;
  • jobb megértést biztosít, ha a kódot hosszú idő után újrafelhasználják.

Kihívások[szerkesztés]

Az elnevezési egyezmények megválasztása (és azok végrehajtásának mértéke) gyakran vitatott kérdés, amikor a résztvevők a saját módszereiket tartják a legjobbnak, míg másokét csak mellékesnek. Sőt, még akkor is, ha az ismert és jól definiált elnevezési konvenciók vannak érvényben, egyes szervezetek nem követik következetesen azokat, így észszerűtlenséget és zavart okoznak az elnevezésekben. Ezeket a kihívásokat súlyosbíthatja, ha a nevek elnevezési konvenciójának szabályai a szervezeten belül következetlenek, önkényesek, nehezen megjegyezhetők, vagy inkább nehézkesebbek, mint hasznosak.

Olvashatóság[szerkesztés]

A jól megválasztott azonosítók jelentősen megkönnyítik a fejlesztők és elemzők számára, hogy megértsék, mit csinál a rendszer, és hogyan javíthatják vagy bővíthetik a forráskódot az új igények kielégítéséhez.

Például az alábbi állítás 

 a = b * c;

szintaktikailag helyes, célja azonban nem egyértelmű. Ezzel ellentétes: 

 weekly_pay = hours_worked * hourly_pay_rate;

ami magában foglalja a forráskód szándékát és jelentését, de csak azok számára, akik ismerik az állítás kontextusát.

Közös elemek[szerkesztés]

Az elnevezési konvenció pontos szabályai attól függnek, hogy milyen körülmények között alkalmazzák őket. Mindazonáltal létezik néhány általános alkotóelem, amelyek befolyásolják a legtöbb, ha nem az összes közhasználatban lévő elnevezési konvenciót.

Az azonosítók hossza[szerkesztés]

Az összes elnevezési konvenció alapvető elemei az azonosító hosszával kapcsolatos szabályok (azaz az azonosítóban megengedett egyedi karakterek véges száma). Egyes szabályok rögzített numerikus hosszt írnak elő, míg mások kevésbé pontos heurisztikát vagy iránymutatást határoznak meg.

Az azonosító hosszúságára vonatkozó szabályokat a gyakorlatban rendszerint vitatják, és tudományos szempontból is több vita tárgyát képezik.

Néhány szempont:

  • célszerűbb lehet a rövidebb azonosítók használata, mivel ezeket könnyebb leírni (bár sok IDE és szövegszerkesztő biztosítja a szöveg automatikus kitöltését, ami már megkönnyíti hosszabb azonosítók használatát is)
  • a rendkívül rövid azonosítókat (például „i” vagy „j”) nagyon nehéz egyértelműen megkülönböztetni az automatizált kereső és cserélő eszközök használatával (bár ez nem jelent problémát a regex alapú eszközök esetében)
  • a hosszabb azonosítók előnyösebbek lehetnek, mivel a rövid azonosítók nem tudnak elegendő információt hordozni, vagy túl rejtélyesnek tűnhetnek
  • a hosszabb azonosítók a vizuális zavar miatt hátrányosak lehetnek

Nyílt kutatási kérdés, hogy egyes programozók inkább a rövidebb azonosítókat részesítik-e előnyben, mivel azokat könnyebb leírni vagy átgondolni, mint a hosszabb azonosítókat, vagy mert sok esetben a hosszabb azonosítók egyszerűen telezsúfolják a látható kódot, és nem biztosítanak érzékelhetőbb előnyt.

Az azonosítók rövidsége a programozásban a következőknek tulajdonítható:

  • korai linkerek, amelyeknél a változóneveket 6 karakterre kellett korlátozni a memória megtakarítása érdekében. A későbbi „előrehaladás” lehetővé tette a hosszabb változónevek használatát, hogy a felhasználók számára érthetőbb legyen, de csak az első néhány karakter volt szignifikáns. A BASIC egyes verzióiban, például a TRS-80 Level 2 Basic-nél, a hosszú nevek megengedettek voltak, de csak az első két betű volt szignifikáns. Ez a szolgáltatás azonban lehetővé tette a hibás viselkedést, amelyet csak nehézkesen lehetett megkeresni, például amikor a "VALUE" és a "VAL" neveket használták a megkülönböztetésre.
  • a korai forráskód-szerkesztőknek nincs automatikus kiegészítése
  • korai alacsony felbontású monitorok korlátozott sorhosszal rendelkeztek (pl: csak 80 karakter)
  • a számítástechnika nagy része a matematikából származik, ahol a változó nevek hagyományosan csak egy betűből álltak

Betűk és számok[szerkesztés]

Néhány elnevezési konvenció korlátozza, hogy a betűk lehetnek-e nagy- vagy kisbetűk. Más konvenciók nem korlátozzák a betűk írásmódját, hanem egy jól definiált értelmezést csatolnak ezzel kapcsolatban. Néhány elnevezési konvenció meghatározza, hogy lehet-e alfabetikus, numerikus vagy alfanumerikus karaktereket használni, és ha igen, milyen sorrendben.

Többszavas azonosítók[szerkesztés]

Egy általános javaslat: "Használj sokatmondó azonosítókat!". Egyetlen szó nem lehet annyira értelmes vagy konkrét, mintha több szót használnánk. Következésképpen néhány elnevezési konvenció meghatározza a több szót tartalmazó "összetett" azonosítók kezelésének szabályait.

Mivel a programozási nyelvek többsége nem engedélyezi a szóközt az azonosítókban, minden szót meg kell határozni (hogy megkönnyítsük a további olvasók számára, hogy melyik karakter melyik szóhoz tartozik). Történelmileg néhány korai nyelv, nevezetesen a FORTRAN (1955) és az ALGOL (1958), megengedte a szóközöket az azonosítókban, meghatározva az azonosítók végét kontextus szerint. Ezt későbbi nyelvekben elhagyták a tokenizálás nehézségei miatt. A neveket egyszerűen a szavak összefűzésével lehet leírni, és ezt néha úgy használják, mint például a mypackage esetében a Java csomagnevekhez.[2] Mivel az értelmezése hosszabb időt vesz igénybe, ezért általában az elválasztás valamilyen formáját alkalmazzák.

Elválasztó karakterrel elválasztott szavak[szerkesztés]

Az egyik megközelítés az, hogy különálló szavakat nem alfanumerikus karakterrel választjuk el. Az e célra általánosan használt két karakter a kötőjel ("-") és az aláhúzás ("_"); például a két szóból álló nevet „two words” írhatjuk, mint „two-words” vagy „two_words”. A kötőjelet már szinte minden régi programozási nyelv használja: a COBOL (1959), Forth (1970) és Lisp (1958). Ugyancsak megszokott az Unixban a parancsok és csomagok esetében is, és a CSS-ben is használatos.[3] Ennek a konvenciónak nincs szabványneve, bár hivatkozhatunk lisp-case-re vagy COBOL-CASE-re (összehasonlítva a Pascal-case-l), kebab-case-re, brochette-case-re vagy más változatra.[4] [5] [6] [7] Ezek közül a kebab-case, ami még 2012-re datálódik,[8] és azóta is használatban van.[9] [10]

Ezzel ellentétben, a FORTRAN/ALGOL tradícióit követő nyelvek, nevezetesen a C és PASCAL családba tartozó nyelvek, a kötőjelet használták a kivonás infix operátorának, és nem követelték meg a szóközök használatát a kötőjel előtt és után, (mint a szabad forma nyelvek), meggátolva ezzel az azonosítókban való használatát. Alternatív megoldás az aláhúzás használata kisbetűs szavakkal, ez gyakori a C programnyelvek családjában (beleértve a Python-t is), és snake case néven vált ismertté. Az aláhúzásokat nagybetűvel, mint az UPPER_CASE esetében, általánosan használják a C előfeldolgozó makrókra, azaz MACRO_CASE néven, valamint a környezeti változókra az Unix-ban, például mint a BASH_VERSION bash-ban. Ezt néha humorosan SCREAMING_SNAKE_CASE-nek nevezik.

Betűkkel elválasztott szavak[szerkesztés]

Egy másik megközelítési mód a szóhatárok jelölése, a középső nagybetű segítségével, amit angolul „ camelCase”-nek, „Pascal case-nek” és még sokféleképpen nevezhetünk, így például a „ two words ” kifejezés „twoWords” vagy „TwoWords” lenne. Ezt a konvenciót általában a Pascal, a Java, a C# és a Visual Basic nyelveknél használják. Az inicializációk kezelése az azonosítókban (pl. "XML" és "HTTP" az XMLHttpRequest) változó. Egyesek azt állítják, hogy kisbetűvel kell írni (pl: XmlHttpRequest) a gépelés és az olvashatóság megkönnyítése érdekében, míg mások nagybetűt használnak (pl:XMLHTTPRequest) a pontosság kedvéért.

Metaadatok és hibrid konvenciók[szerkesztés]

Egyes elnevezési konvenciók olyan szabályokat vagy követelményeket képviselnek, amelyek meghaladják egy adott projekt vagy problémakör követelményeit, ehelyett inkább a szoftver architektúrája, az alapjául szolgáló programozási nyelv vagy más típusú projektek közötti módszertan által definiált átfogóbb alapelveket tükrözik.

Magyar jelölés[szerkesztés]

Talán a legismertebb a magyar jelölés, amely a nevében egy változó rendeltetését ("Apps Hungarian") vagy típusát ("Systems Hungarian") kódolja.[11] Például a szName változó "sz" előtagja azt jelzi, hogy a változó null-végű karakterlánc.

Helyiértékes jelölés[szerkesztés]

A nagyon rövid (legfeljebb nyolc karakter) stílus lehet: LCCIIL01, ahol LC (Letters of Credit) lenne az alkalmazás, C a COBOL programnyelvet jelöli, IIL az adott folyamat-részhalmaza, és a 01 a sorszáma.

Ez a fajta konvenció továbbra is aktívan használatban van a JCL-től függő nagyszámítógépekben, és ez is látható a 8.3 (legfeljebb nyolc karakter periodikus elválasztóval, amit három karakterű fájltípus követ) MS-DOS stílusban.

Összetett szórendszer (OF Language)[szerkesztés]

Az IBM „OF Language”-ét az IMS (Információkezelő Rendszer) kézikönyvében dokumentálták.

Bemutatta a PRIME-MODIFIER-CLASS szórendszert, amely olyan nevekből állt, mint a "CUST-ACT-NO", ami az "ügyfélszámla számot" jelölte.

A PRIME szavak célja, hogy jelöljék a rendszernek a jelentősebb "entitásait".

A MODIFIER szavakat használták a további finomításhoz, minősítéshez és olvashatósághoz.

A CLASS szavak ideális esetben az adott alkalmazás szempontjából releváns adattípusoknak egy nagyon rövid listáját tették ki. Gyakori CLASS szavak lehetnek: NO (szám), ID (azonosító), TXT (szöveg), AMT (összeg), QTY (mennyiség), FL (állapotjelző), CD (kód), W (munka) és így tovább. A gyakorlatban a rendelkezésre álló CLASS szavak kevesebb mint két tucat kifejezést jelentenek.

A CLASS szavak, általában a jobb oldalon (utótagként) vannak elhelyezve, nagyjából ugyanazt a célt szolgálják, mint a magyar jelölésben az előtagok.

A CLASS szavak célja a következetesség, mellett az volt, hogy meghatározza az adattípusát egy adott adatmezőnek a programozó számára. A BOOLEAN (csak két érték) mező elfogadása előtt az FL (állapotjelző) csak két lehetséges értékkel rendelkező mezőt jelölne.

Nyelvspecifikus egyezmények[szerkesztés]

ActionScript[szerkesztés]

Az Adobe kódolási egyezményei és a Best Practices elnevezési szabványokat javasolnak az ActionScript-hez, amelyek többnyire megegyeznek az ECMAScript szabványaival. Az azonosítók stílusa hasonló a Java stílusához.

Ada[szerkesztés]

Adaban az azonosítók egyetlen ajánlott stílusa a Mixed_Case_With_Underscores.[12]

APL[szerkesztés]

Az APL nyelvben a deltát (Δ) használják a szavak között, például: PERFΔSQUARE (a régebbi APL verziókban hagyományosan nem létezett kisbetű). Ha a név aláhúzott betűket használ, akkor a delta alsó sávot (⍙) használják a sima delta (Δ) helyett.

C és C++[szerkesztés]

A C és a C++ kategóriában a kulcsszavak és a standard könyvtári azonosítók általában kisbetűsek. A C standard könyvtárban a rövidített nevek a leggyakoribbak (például isalnum egy olyan függvény, amely ellenőrzi, hogy a karakterek alfanumerikusak-e vagy nem), addig a C ++ standard könyvtár gyakran aláhúzást használ a szavak szétválasztására (pl. out_of_range). A makrókat ábrázoló azonosítókat megegyezés szerint csak nagybetűkkel és aláhúzásokkal írják (ez összefügg azzal a konvencióval sok programozási nyelvben, hogy nagybetűs azonosítókat használnak az állandókhoz). Kettős aláhúzással vagy aláhúzással és nagybetűvel kezdődő nevek (pl. __reserved vagy _Reserved) a végrehajtáshoz vannak fenntartva (fordító, standard könyvtár), és nem használhatók máshol.[13] [14] Ez felületesen hasonlít a stropping-ra, de a szemantika különbözik: az alul vonások az azonosító értékének részei, mintsem idézőjel karakterek lennének (mint a stropping-ban): a __foo értéke __foo (mely lefoglalt), nem foo (csak egy másik névtérben).

C#[szerkesztés]

A C# elnevezési konvenciók általában a Microsoft által közzétett irányelveket követik minden .NET nyelvnél[15] (lásd az alább található .NET szakasz), de a konvenciókat a C# fordító nem erőlteti.

A Microsoft iránymutatásaiban kizárólag a PascalCase és a camelCase használatát javasolja, az utóbbi csak a metódus paraméterek és a metódusok helyi változónevek (beleértve a metódus helyi const értékeit) használatára szolgál. Különleges kivétel a PascalCase-nél azon kétbetűs rövidítéseknél van, amelyek azonosítót kezdenek; ezekben az esetekben mindkét betű nagybetű (például IOStream); hosszabb rövidítéseknél ez nem igaz (például XmlStream). Az iránymutatások azt is javasolják, hogy az interface neve PascalCase legyen, amelyet az "I" nagybetű előz meg, mint az IEnumerable.

A mezők elnevezésére vonatkozó Microsoft iránymutatások a static, public és protected mezőkre vonatkoznak; a nem static és más hozzáférhetőségi szintű (például internal és private) mezőket az iránymutatások kimondottan nem fedik le.[16] A legelterjedtebb gyakorlat a PascalCase használata minden mező nevére, kivéve a private (és nem const vagy static) mezőket, valamint azokat a neveket, amelyek camelCase-t használnak, illetve amelyeket egyetlen aláhúzás előz meg; például _totalCount.

Bármely azonosító nevet megelőzhet a kereskedelmi at (@) szimbólum, jelentésének változása nélkül. Vagyis a factor és @factor ugyanarra az objektumra utal. A konvenció alapján, ezt az előtagot csak akkor kell használni, ha az azonosító egyébként egy fenntartott kulcsszó (mint például for és while), amelyeket nem lehet használni úgy, mint egy azonosítót előtag nélkül, vagy egy kontextus szerinti kulcsszót (mint például from és where), amely esetében az előtagot nem kell szigorúan megkövetelni (legalábbis nem a deklarációknál; annak ellenére például, hogy a deklaráció érvényes: dynamic dynamic;, de ezt általában dynamic @dynamic;-nek tekintik, így azonnal jelezve az olvasónak, hogy az utóbbi egy változó neve).

Go[szerkesztés]

A Go programozási nyelvben az a konvenció, hogy a MixedCaps vagy mixedCaps elnevezéseket használjuk, mint az aláhúzást a többszavas nevek írására. Osztályokra vagy függvényekre való hivatkozáskor az első betű a külső csomagok láthatóságát adja meg. Az első betű nagybetűvé tétele exportálja ezt a kódot, míg a kisbetűk csak a jelenlegi hatókörön belüli használatot engedik.[17]

Java[szerkesztés]

A Javaban számos Java programozói közösség hozta létre és javasolta az azonosítók elnevezési konvencióit, például a Sun Microsystems,[18] Netscape,[19] AmbySoft,[20] stb. Az alábbiakban példákat sorolunk fel a Sun Microsystems által készített elnevezési konvenciókról, ahol a "CamelCase" név több szóból áll, szóközök nélkül összekapcsolva, és minden szó kezdőbetűje nagybetű - például mint maga a "CamelCase".

Azonosító típusa Az elnevezés szabályai Példák
osztályok

(Classes)

Az osztályneveknek főneveknek kell lenniük az Upper CamelCaseben, és minden szó első betűjét nagybetűvel kell írni. Használjunk egész szavakat, kerüljük el a mozaikszavakat és a 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).
  • class Raster {}
  • class ImageSprite {}
Metódusok (Methods) A metódusoknak lower CamelCasenek kell lenniük vagy több szavas neveknek, amelyek kisbetűs igével kezdődnek, vagyis az első betű kisbetű és a következő szavak első betűi nagybetűk.
  • run();
  • runFast();
  • getBackground();
Változók (Variables) A helyi változók, a példányváltozók és az osztályváltozók szintén a lower CamelCaselel vannak írva. A változóneveknek nem szabad aláhúzással (_) vagy dollárjelekkel ($) kezdődniük, bár mindkettő megengedett. Ez ellentétben van más kódolási konvenciókkal, amelyek kimondják, hogy az aláhúzást kell használni az összes példányváltozó előtagjához.

A változó neveknek rövidnek, de értelmesnek kell lenniük. A változó nevet úgy kell megválasztani, hogy jelezze az átlagos megfigyelőnek a változó használatának szándékát. Kerülni kell az egy karakteres változóneveket, kivéve az átmeneti "eldobható" változókat. Az ideiglenes változók általános nevei: "i, j, k, m és n" az egész számoknál; "c, d és e" a karaktereknél.

  • int i;
  • char c;
  • float myWidth;
Konstansok (Constants) A konstansokat nagybetűkkel kell írni, aláhúzással elválasztva. A konstansok nevei tartalmazhatnak számjegyeket is, ha szükséges, de nem első karakterként.
  • static final int MAX_PARTICIPANTS = 10;

A Java fordítók nem erőltetik ezeket a szabályokat, de azok be nem tartása zavart és hibás kódot eredményezhet. Például a widget.expand() és a Widget.expand()jelentősen eltérő viselkedést von maga után: a widget.expand() az expand() metódus meghívását jelenti a widget nevű példányban, míg a Widget.expand() az expand() statikus metódus meghívását jelenti a Widget osztályban.

Az egyik széles körben is használt Java kódolási stílus azt írja elő, hogy az UpperCamelCase-t osztályokhoz kell használni, az lowerCamelCase-t pedig példányokhoz és metódusokhoz.[18] Ezt a felhasználást felismerve az egyes IDE-k, például az Eclipse, CamelCase alapú rövidítéseket hozott létre. Az Eclipse tartalomsegéd szolgáltatásában a CamelCase írásmódú szó nagybetűinek beírása bármilyen ezzel egyező osztály- vagy metódusnevet feldobhat (például: az „NPE” beírására a tartalomsegédet aktiválva javasolhatja a NullPointerException-t).

Három vagy több betűs betűszavaknál CamelCase-t kell használni nagybetűs jelölés helyett (pl:parseDBMXMLFromIPAddresshelyett parseDbmXmlFromIPAddress). Ezt a kikötést két vagy több betűre is alkalmazhatjuk (pl. parseDbmXmlFromIpAddress).

JavaScript[szerkesztés]

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 UpperCamelCase-t használnak (RegExp, TypeError, XMLHttpRequest, DOMObject), a metódusok pediglowerCamelCase-t (getElementById, getElementsByTagNameNS, createCDATASection). A következetesség érdekében a legtöbb JavaScript fejlesztő betartja ezeket a konvenciókat.[21] Lásd még: Douglas Crockford konvenciói

Lisp[szerkesztés]

Bevett szokás a legtöbb Lisp programozási nyelvben a kötőjelek használata a szavak megkülönböztetésére az azonosítókban, mint például az with-open-file és a make-hash-table. A dinamikus változónevek általában csillag (*) szimbólummal kezdődnek és végződnek: *map-walls*. Az állandók nevét pluszjelek (+) jelzik: +map-size+.[22] [23]

.NET[szerkesztés]

A Microsoft .NET a UpperCamelCase használatát ajánlja (más néven a PascalCase-t) a legtöbb azonosítóhoz (a LowerCamelCase ajánlott a paraméterek és a változók elnevezéséhez), és ezek az ajánlások megegyeznek a .NET alapú nyelvek esetében.[24] Továbbá a Microsoft azt javasolja, hogy ne használjunk utalásokat a típus előtagjaként (más néven magyar jelölést).[25] A magyar jelölés helyett az az elfogadott, hogy az elnevezéseket az alaposztály nevével zárjuk le: BtnLoginhelyettLoginButton.[26]

Objective-C[szerkesztés]

Az Objective-C általános kódolási stílusának az alapja a Smalltalk.

A legfelső szintű entitások, beleértve az osztályokat, protokollokat, kategóriákat, valamint a C konstrukciókat, amiket az Objective-C programokban használnak, mint a globális változók és függvények, az UpperCamelCase-ben egy rövid, nagybetűs előtaggal vannak ellátva, amelyek a névteret jelölik, például NSString, UIAppDelegate, NSApp vagy CGRectMake. A konstansok opcionálisan előtagolhatók kisbetűs "k" betűvel, például a kCFBooleanTrue.

Az objektum példányváltozói az aláhúzással kezdett lowerCamelCase-t használják, mint például a _delegate és _tableView.

A metódusnevek lowerCamelCase-t használnak több részletben, kettőspontokkal elválasztva, az argumentumokat körülhatárolva, például: application:didFinishLaunchingWithOptions :, stringWithFormat: és isRunning.

Pascal, Modula-2 és Oberon[szerkesztés]

A Wirthian nyelvek, mint a Pascal, a Modula-2 és az Oberon általában Capitalized vagy UpperCamelCase azonosítókat használ a programokhoz, modulokhoz, konstansokhoz, típusokhoz és eljárásokhoz, valamint lowercase vagy lowerCamelCase-el ellátott azonosítókat a matematikai állandókhoz, változókhoz, formális paraméterekhez és függvényekhez.[27] Míg néhány nyelv támogatja az aláhúzást és a dollárjeleket az azonosítókban, Snake case és a Macro case inkább a külső API interfészeken való használatra korlátozódik.[28]

Perl[szerkesztés]

Perl programozási nyelv néhány utasítását a C programozási nyelv hagyatékából veszi át a konvencióihoz. A lokális változók és az alprogramok neve kisbetűs, infix aláhúzással. Azok a alprogramok és változók, amelyeket privátként kell kezelni, aláhúzással vannak megjelölve. A csomagváltozók és a deklarált konstansok írásmódja mind nagybetűs. A csomagnevek CamelCase használatát követik, kivéve a pragmatát - pl. strict és mro,amelyek kisbetűsek.[29] [30]

PHP[szerkesztés]

A PHP ajánlásokat a PSR-1 és a PSR-12 tartalmazza.[31] A PSR-1 alapján az osztályneveket PascalCase alapján kell elnevezni, míg az osztály szintű konstansokat MACRO_CASE szerint, az eljárásneveket pedig a camelCase alapján.[32]

Python és Ruby[szerkesztés]

A Python és a Ruby az UpperCamelCase használatát javasolja az osztálynevekhez, a CAPITALIZED_WITH_UNDERSCORES használatát a konstansok nevéhez, és alowercase_separated_by_underscores elnevezést pedig a többi elnevezéshez.

A Pythonban, ha egy név privát mezőt jelöl, akkor azt az elnevezés elején aláhúzással jelöljük. A privát változókat Pythonban csak konvenció alapján hozzák létre. A nevek után aláhúzást is írhatunk, hogy elkerüljük a Python kulcsszavakkal való ütközést. A kettős aláhúzású előtag megváltoztatja a viselkedést az osztályokban a névroncsolást (name mangling) illetően. Az dupla aláhúzással ellátott elő- és utótagokat azoknak a "mágikus neveknek" (magic names) tartják fenn, amelyek a különleges viselkedésnek tesznek eleget a Python-objektumokban.[33]

R[szerkesztés]

Míg nincs hivatalos stílusszabály az R-hez, így az R-guru, Hadley Wickham átfogó stílusú útmutatója adja a standard alapot a legtöbb felhasználó számára.[34] Az útmutató azt javasolja, hogy kerüljük a speciális karaktereket a fájlnevekben, és csak a számokat, betűket és aláhúzást használjuk a változó- és függvénynevekhez, pl. fit_models.R.

Raku[szerkesztés]

Raku többé-kevésbé ugyanazokat a konvenciókat követi, mint a Perl, azzal az eltéréssel, hogy lehetővé tesz egy infix kötőjelet (vagy egy aposztrófjelet) egy azonosítóban (de kettőt egymás után már nem), feltéve, hogy azt az ábécé egy karaktere követi. A Raku nyelvben programozók így gyakran kebab case-t használnak a azonosítóikban; például érvényes azonosítók lehetnek a fish-food és a don't-do-that.[35]

Rust[szerkesztés]

A Rust az UpperCamelCase-t ajánlja álnevek, struct, trait, enum, és enum variáns nevek írásához, SCREAMING_SNAKE_CASE-et a konstans vagy statikus mezőkhöz és snake_case-t a változók, függvények és struct tagok neveihez.[36]

Swift[szerkesztés]

A Swift minden kiadásainál megváltoztatta az elnevezési konvencióit. Azonban a Swift 3.0 jelentős frissítése lowerCamelCase írásmódban rögzítette az elnevezési konvenciókat a változóknál és a funkcionális deklarációknál. A konstansokat általában enum típusok vagy konstans paraméterek határozzák meg, amelyeket szintén így írnak. Az osztály és egyéb objektumtípusú deklarációk UpperCamelCase-ben íródnak.

Swift 3.0 verziójától kezdve egyértelmű irányelvek születtek a nyelvhez annak érdekében, hogy az API elnevezési és deklarálási konvencióit egységesítsék az összes harmadik fél API-ján.[37]

Jegyzetek[szerkesztés]

  1. ↑ Derek M. Jones "Operand names influence operator precedence decisions" An experiment investigating the effect of variable names on operator precedence selection
  2. ↑ Naming a Package
  3. ↑ CSS reference. Mozilla Developer Network. (Hozzáférés: 2016. június 18.)
  4. ↑ StackOverflow – What's the name for snake_case with dashes?
  5. ↑ Programmers – If this is camelCase what-is-this?. [2016. augusztus 7-i dátummal az eredetiből archiválva]. (Hozzáférés: 2020. június 25.)
  6. ↑ Camel_SNAKE-kebab, 2019. szeptember 1.
  7. ↑ UnderscoreVersusCapitalAndLowerCaseVariableNaming
  8. ↑ jwfearn: Revisions to jwfearn's answer to What's the name for dash-separated case?, 2012. szeptember 5.
  9. ↑ Living Clojure (2015), by Carin Meier, p. 91
  10. ↑ lodash: kebabCase
  11. ↑ Making Wrong Code Look Wrong, 2005. május 11.
  12. ↑ http://www.adaic.org/resources/add_content/docs/95style/html/sec_3/3-2-1.html
  13. ↑ ISO/IEC 9899:1999 Programming languages – C. ISO
  14. ↑ ISO/IEC 14882:2011 Information technology – Programming languages – C++. ISO
  15. ↑ Naming Guidelines. Microsoft
  16. ↑ Names of Type Members. Microsoft
  17. ↑ Effective Go - the Go Programming Language
  18. ↑ a b "Code Conventions for the Java Programming Language", Section 9: "Naming Conventions"
  19. ↑ "NETSCAPE'S SOFTWARE CODING STANDARDS GUIDE FOR JAVA",Collab Software Coding Standards Guide for Java Archiválva 2009. március 3-i dátummal a Wayback Machine-ben.
  20. ↑ "AmbySoft Inc. Coding Standards for Java v17.01d"
  21. ↑ Morelli: 5 JavaScript Style Guides – Including AirBnB, GitHub, & Google. codeburst.io, 2017. november 17. (Hozzáférés: 2018. augusztus 17.)
  22. ↑ Variables
  23. ↑ Naming conventions on CLiki
  24. ↑ Microsoft .NET Framework Capitalization Styles
  25. ↑ .NET Framework Developer's Guide – General Naming Conventions
  26. ↑ [Framework Design Guidelines, Krzysztof Cwalina, Brad Abrams Page 62]
  27. ↑ Modula-2 Name Convention. [2016. szeptember 10-i dátummal az eredetiből archiválva]. (Hozzáférés: 2020. június 25.)
  28. ↑ Foreign API Identifiers in Modula-2 Name Convention. [2016. szeptember 10-i dátummal az eredetiből archiválva]. (Hozzáférés: 2020. június 25.)
  29. ↑ Perl style guide. [2013. június 26-i dátummal az eredetiből archiválva]. (Hozzáférés: 2020. június 25.)
  30. ↑ perlmodlib – constructing new Perl modules and finding existing ones
  31. ↑ PHP standards recommendations
  32. ↑ https://www.php-fig.org/psr/psr-1/
  33. ↑ Style Guide for Python Code PEP8
  34. ↑ Style Guide for RCode
  35. ↑ General rules of Perl 6 syntax
  36. ↑ Naming conventions (angol nyelven). doc.rust-lang.org. (Hozzáférés: 2018. február 4.)
  37. ↑ swift.org API Design Guidelines

Fordítás[szerkesztés]

Ez a szócikk részben vagy egészben a Naming convention (programming) című angol Wikipédia-szócikk ezen változatának fordításán alapul. Az eredeti cikk szerkesztőit annak laptörténete sorolja fel. Ez a jelzés csupán a megfogalmazás eredetét és a szerzői jogokat jelzi, nem szolgál a cikkben szereplő információk forrásmegjelöléseként.

Kapcsolódó szócikkek[szerkesztés]

További információk[szerkesztés]

A lap eredeti címe: „https://hu.wikipedia.org/w/index.php?title=Elnevezési_konvenciók_(programozás)&oldid=26924185”