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;Derek M. Jones "Operand names influence operator precedence decisions" An experiment investigating the effect of variable names on operator precedence selection 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 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 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 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 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 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 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 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.Naming a Package 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 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. 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.UnderscoreVersusCapitalAndLowerCaseVariableNaming Ezek közül a kebab-case, ami még 2012-re datálódik, és azóta is használatban van.Living Clojure (2015), by Carin Meier, p. 91lodash: kebabCase

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 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 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 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. 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 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) 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.