Inom programmering är en namnkonvention en uppsättning regler för namngivning av identifierare som representerar variabler , typer , funktioner och andra saker i källkod och dokumentation .
Konventioner, istället för att använda godtyckliga namn, kan användas för att utföra följande uppgifter:
Valet av namnkonventioner kan vara en extremt kontroversiell fråga, där förespråkare för var och en ser sina konventioner som de bästa och andra som de sämsta. I vanligt språkbruk kallas sådana diskussioner för "holivars" (av engelska holy war - holy war ) [2] . Många företag upprättar sina egna avtal [3] [4] [5] [6] [7] [8] .
Några av de potentiella fördelarna som kan uppnås genom att anta en namnkonvention är:
Valet av namnkonventioner (och i vilken utsträckning de tillämpas) är ofta en omtvistad fråga, där förespråkarna håller fast vid sin synpunkt som den bästa och andra som den sämsta. Dessutom, även om det finns välkända och väldefinierade namnkonventioner, kanske vissa organisationer inte följer dem konsekvent, vilket leder till inkonsekvenser och förvirring. Dessa problem kan förvärras om namnkonventionsreglerna är internt inkonsekventa, godtyckliga, svåra att komma ihåg eller på annat sätt uppfattas som mer betungande än hjälpsamma.
Väl valda identifierare gör det mycket lättare för utvecklare och analytiker att förstå vad systemet gör och hur man fixar eller utökar källkoden för att tillämpa den på nya behov.
Till exempel, även om
a = b * c;syntaktisk korrekt är dess syfte inte uppenbart. Jämför detta med:
weekly_pay = hours_worked * hourly_pay_rate;vilket innebär att man förstår källkoden, åtminstone för dem som är bekanta med påståendets sammanhang.
De exakta reglerna för namnkonventioner beror på i vilket sammanhang de används. Det finns dock några vanliga element som påverkar de flesta, om inte alla, namnkonventioner som används idag.
De grundläggande elementen i alla namnkonventioner är regler som hänför sig till längden på en identifierare (det vill säga det ändliga antalet distinkta tecken som tillåts i en identifierare). Vissa regler föreskriver en fast numerisk gräns, medan andra specificerar mindre exakta värden eller riktlinjer.
Regler för identifieringslängd är ofta ifrågasatta i praktiken och är föremål för mycket vetenskaplig debatt.
Några överväganden:
Det är en öppen fråga om forskning om vissa programmerare föredrar kortare identifierare för att de är lättare att skriva eller komma på än längre identifierare, eller för att en längre identifierare i många situationer helt enkelt belamrar den synliga koden och inte ger någon synlig extra fördel.
Kortheten i programmering förklaras delvis av:
Vissa namnkonventioner begränsar visningen av bokstäver med versaler eller gemener. Andra konventioner begränsar inte skiftläge, utan lägger till en väldefinierad tolkning baserad på skiftläge. Vissa namnkonventioner anger om alfabetiska, numeriska eller alfanumeriska tecken kan användas, och i så fall i vilken ordning.
Den allmänna rekommendationen är "Använd meningsfulla identifierare". Ett ord kanske inte är lika meningsfullt eller specifikt som flera ord. Därför specificerar vissa namnkonventioner regler för hantering av "sammansatta" identifierare som innehåller mer än ett ord.
Eftersom de flesta programmeringsspråk inte tillåter mellanslag i identifierare behövs en metod för att separera varje ord (för att göra det lättare för efterföljande läsare att tolka vilka tecken som hör till vilket ord). Historiskt sett har vissa tidiga språk, särskilt FORTRAN (1955) och ALGOL (1958), tillåtit mellanslag i identifierare genom att bestämma slutet av identifierare genom sammanhang. Detta har övergetts på senare språk på grund av svårigheten att tokenisera . Det är möjligt att skriva namn genom att helt enkelt sammanfoga ord, och detta används ibland, som i mypackageJava-paketnamn [9] , även om läsbarheten blir lidande med längre termer, så någon form av separation används vanligtvis.
Avgränsningsseparerade ordEtt tillvägagångssätt är att separera enskilda ord med icke-alfanumeriska tecken. Två tecken används vanligtvis för detta ändamål: ett bindestreck ("-") och ett understreck ("_"); till exempel «two words»skulle ett tvåordsnamn representeras som «two-words»eller «two_words». Bindestrecket används av nästan alla COBOL (1959), Forth (1970) och Lisp (1958) programmerare; det är också vanligt i Unix för kommandon och paket, och används i CSS [10] . Denna konvention har inget standardnamn, även om den kan kallas lisp-case eller COBOL-CASE (jämför Pascal-case ), kebab-case , brochette-case eller andra varianter [11] [12] [13] [14] . Av dessa har case-kebaben , med anor från åtminstone 2012 [15] , sedan dess blivit populär [16] [17] .
Däremot använde språk i FORTRAN/ALGOL-traditionen, särskilt de från C- och Pascal-familjerna, bindestrecket för infix-subtraktionsoperatorn och ville inte kräva mellanslag runt det (som språk i fritt format), vilket förhindrade dess använda i identifierare. Ett alternativ är att använda ett understreck; detta är vanligt i C-familjen (inklusive Python), där ord med små bokstäver förekommer, t.ex. i programmeringsspråket C (1978) och blev känt som snake case . Versaler understreck, som i UPPER_CASE, används vanligtvis för C-förprocessormakron , så de är kända som MACRO_CASE, och för Unix- miljövariabler som BASH_VERSION i bash . Detta kallas ibland humoristiskt för SCREAMING_SNAKE_CASE.
Ord åtskilda av bokstäverEtt annat tillvägagångssätt är att indikera ordgränser med hjälp av mellankapslar som kallas " camelCase ", "Pascal case" och många andra namn, vilket visas «two words»som «twoWords»eller respektive «TwoWords». Denna konvention används ofta i Pascal , Java , C# och Visual Basic . Hanteringen av initialismer i identifierare (som " XML " och " HTTP " i XMLHttpRequest) varierar. Vissa tycker att de ska vara i gemener (t.ex. XmlHttpRequest) för att det ska vara lättare att skriva och läsa, medan andra lämnar dem med versaler (t.ex. XMLHTTPRequest) för att de ska vara korrekta.
Exempel på utförliga identifierarformat| Formatera | namn |
|---|---|
| twowords | platt fall [18] [19] |
| TWOWORDS | övre platt fodral [18] |
| twoWords | (nedre) camelCase , dromedarCase |
| TwoWords | (övre) CamelCase , PascalCase, StudlyCase [20] |
| two_words | ormfall , pothole_case |
| TWO_WORDS | SKRIKER SNAKE CASE , MACRO_CASE, CONSTANT_CASE |
| Two_Words | Camel_Snake_Case [21] |
| two-words | kebab-fodral , dash-fodral, lisp-fodral |
| TWO-WORDS | TÅG-CASE, COBOL-CASE, SREAMING-KEBAB-CASE |
| Two-Words | Train-Case, [18] HTTP-Header-Case [21] |
Vissa namnkonventioner är regler eller krav som går utöver kraven för ett visst projekt eller en viss domän, och istället speglar en bredare uppsättning principer som definieras av en mjukvaruarkitektur , underliggande programmeringsspråk eller annan projektöverskridande metodik.
Den kanske mest kända är den ungerska notationen , som kodar antingen syftet ("Apps Hungarian") eller typen ("Systems Hungarian") av en variabel i dess namn [22] . Till exempel anger prefixet "sz" för variabeln szName att variabeln är en nollterminerad sträng.
Stilen som används för mycket kort (åtta tecken eller färre) kan vara: LCCIIL01, där LC är bilaga (brev), C för COBOL, IIL för en specifik delmängd av processer och 01 är ett sekvensnummer.
Denna konvention är fortfarande i aktiv användning i stordatorer beroende på JCL, och finns även i MS-DOS 8.3-stilen (maximalt åtta tecken med en separerande punkt följt av en filtyp med tre tecken).
IBMs "OF Language" dokumenterades i IMS-manualen ( Information Management System ).
Den beskriver ordschemat PRIME-MODIFIER-CLASS, som består av namn som "CUST-ACT-NO" för "kundkontonummer".
Orden PRIME var avsedda att beteckna de huvudsakliga "enheterna" av intresse för systemet.
Orden MODIFIER har använts för ytterligare förtydligande, förfining och läsbarhet.
Helst skulle orden KLASS vara en mycket kort lista över applikationsspecifika datatyper. Vanliga KLASS-ord kan vara: NO (nummer), ID (identifierare), TXT (text), AMT (mängd), QTY (kvantitet), FL (flagga), CD (kod), W (arbete) etc. I praktiken , kommer de tillgängliga KLASS-orden att vara en lista med mindre än två dussin termer.
Orden KLASS, som vanligtvis placeras till höger (suffix), tjänar nästan samma syfte som den ungerska beteckningen prefix .
Syftet med KLASS-orden var, förutom konsekvens, att indikera för programmeraren datatypen för ett visst datafält. Innan BOOLEAN (endast två värden) fält accepteras, kommer FL (flagga) att peka på ett fält med endast två möjliga värden.
Adobes kodningskonventioner och bästa praxis tillhandahåller namnstandarder för ActionScript som till största delen följer ECMAScript- standarderna . Identifierarnas stil liknar den för Java .
I Ada är den enda rekommenderade stilen för identifierare Mixed_Case_With_Underscores[23] .
APL- dialekter använder ett delta (Δ) mellan ord, som PERFΔSQUARE (det fanns traditionellt inga gemener i äldre versioner av APL). Om understrukna bokstäver används i namnet kommer ett understruket deltastreck (⍙) att användas istället.
I C och C++ skrivs standardbiblioteks nyckelord och identifierare oftast med gemener. I C-standardbiblioteket är förkortningar vanligast (till exempel för en funktion som kontrollerar om ett tecken är alfanumeriskt), medan C++-standardbiblioteket ofta använder understreck som ordavgränsare (till exempel ). Identifierare som representerar makron är enligt konvention skrivna med endast versaler och understreck (detta beror på konventionen i många programmeringsspråk att endast använda versaler för konstanter). Namn som innehåller dubbla understreck eller som börjar med ett understreck och en stor bokstav är reserverade för implementeringen ( kompilator , standardbibliotek ) och får inte användas (t.ex. eller ) [24] [25] . Detta är ytligt likt slinging, men semantiken är annorlunda: understreck är en del av identifierarvärdet, snarare än att citera tecken (som slinging): värdet är (vilket är reserverat) inte (men i ett annat namnområde). isalnumout_of_range__reserved_Reserved__foo__foofoo
C# -namnkonventioner följer i allmänhet rekommendationerna som publicerats av Microsoft för alla NET-språk [26] (se NET nedan), men C#-kompilatorn upprätthåller inga konventioner.
Microsofts manual rekommenderar exklusiv användning av endast PascalCase och CamelCase , den senare används endast för parameternamn och metodvariabelnamn för lokala (inklusive metod lokala const) värden. Ett speciellt undantag för PascalCase görs för akronymer med två bokstäver som börjar en identifierare; i dessa fall är båda bokstäverna IOStreambokstäver (till exempel IOStream); detta gäller inte längre akronymer (t.ex. XmlStream). Manualen rekommenderar också att namnet som ges interfaceär PascalCase föregås av ett stort I , som i IEnumerable.
Microsofts riktlinjer för fältnamn gäller för static, publicoch protectedfält; fält som inte är staticoch har andra tillgänglighetsnivåer (till exempel internaloch private) omfattas uppenbarligen inte av [27] riktlinjerna . Den vanligaste metoden är att använda PascalCase för alla fältnamn, förutom de som är private(och varken är const, eller static), som får namn som använder camelCase föregås av ett enda understreck; till exempel _totalCount.
Alla identifierare namn kan börja med ett citattecken ( @ ) utan att ändra innebörden. Det vill säga och factor, och @factorhänvisar till samma objekt. Enligt konventionen används detta prefix endast när identifieraren annars antingen skulle vara ett reserverat nyckelord (till exempel foroch while) som inte kan användas som en identifierare utan prefix, eller ett kontextuellt nyckelord (till exempel fromoch where), i vilket fall prefix krävs inte strikt (åtminstone inte när man deklarerar det; till exempel, även om deklarationen dynamic dynamic;är giltig, ses den vanligtvis som dynamic @dynamic;omedelbart indikerar för läsaren att det senare är ett variabelnamn).
I Go är det vanligt att använda MixedCapseller mixedCapssnarare än understryka för att skriva utförliga namn. När man hänvisar till klasser eller funktioner indikerar den första bokstaven synlighet för externa paket. Om du gör den första bokstaven till versaler kommer detta kodavsnitt att exporteras, medan gemener endast kommer att användas i det aktuella omfånget [28] .
I Java har namnkonventioner för identifierare utvecklats och föreslagits av olika Java-communities såsom Sun Microsystems [29] , Netscape [30] , AmbySoft [31] etc. Exempel på namnkonventioner etablerade av Sun Microsystems listas nedan, där namnet i " CamelCase " består av flera ord sammanlänkade utan mellanslag, med den första stora bokstaven i varje ord, till exempel "CamelCase".
| Identifieringstyp | Namnregler | Exempel |
|---|---|---|
| Klasser | Klassnamn måste vara substantiv i , den första bokstaven i varje ord måste vara versal. Använd hela ord – undvik akronymer och förkortningar (såvida inte förkortningen används mycket bredare än den långa formen, som URL eller HTML). Upper CamelCase |
|
| Metoder | Metoder måste vara verb med kasus eller flerordsnamn som börjar med ett verb med gemener; det vill säga den första bokstaven med gemener och de första bokstäverna i efterföljande ord med versaler. lower CamelCaselower CamelCase |
|
| Variabler | Lokala variabler, instansvariabler och klassvariabler skrivs också till . Variabelnamn får inte börja med ett understreck ( ) eller dollartecken ( ), även om båda är tillåtna. Detta i motsats till andra kodningskonventioner, som säger att alla instansvariabler ska ha understreck.
lower CamelCase_$ Variabelnamn ska vara korta men meningsfulla. Valet av variabelnamn bör vara mnemoniskt, det vill säga avsett att indikera för den tillfällige observatören syftet med dess användning. Variabelnamn med ett tecken bör undvikas, med undantag för tillfälliga "engångsvariabler". Vanliga temporära variabelnamn: i, j, k, m och n för heltal; c, d och e för tecken. |
|
| Konstanter | Konstanter ska skrivas med stora bokstäver åtskilda av understreck. Konstantnamn kan också innehålla siffror om det behövs, men inte som det första tecknet. |
|
Java-kompilatorer tillämpar inte dessa regler, men underlåtenhet att följa dem kan leda till förvirring och felaktig kod. Till exempel, widget.expand()och Widget.expand()antyder väsentligt olika beteende: widget.expand()det innebär ett metodanrop på en expand()instans som heter widget, medan det Widget.expand()innebär ett statiskt metodanrop. expand()i klassen Widget.
En allmänt använd Java-kodningsstil kräver att UpperCamelCase används för klasser och lowerCamelCase för instanser och metoder [29] . Genom att känna igen denna användning implementerar vissa IDE:er som Eclipse genvägar baserade på CamelCase. Till exempel, i Eclipses innehållshjälpfunktion, kommer att skriva med stora bokstäver av ordet CamelCase föreslå ett lämpligt klass- eller metodnamn (exempelvis att skriva "NPE" och aktivera innehållshjälp kan föreslå NullPointerException).
Initialism av tre eller fler bokstäver - CamelCase istället för versaler (till exempel parseDbmXmlFromIPAddressistället för parseDBMXMLFromIPAddress). Du kan också ställa in en ram med två eller flera bokstäver (till exempel parseDbmXmlFromIpAddress).
De inbyggda JavaScript-biblioteken använder samma namnkonventioner som Java. Datatyperna och konstruktorfunktionerna använder versaler ( RegExp , TypeError , XMLHttpRequest , DOMObject ) och metoderna använder gemener ( getElementById , getElementsByTagNameNS , createCDATASection ). För att vara konsekvent följer de flesta JavaScript-utvecklare dessa konventioner [32] [33] .
Vanlig praxis i de flesta Lisp- dialekter är att använda bindestreck för att separera ord i identifierare, som i with-open-fileoch make-hash-table. Dynamiska variabelnamn börjar och slutar vanligtvis med asterisker: *map-walls*. Konstantnamn är markerade med ett plustecken: +map-size+[34] [35] .
Microsoft .NET rekommenderar UpperCamelCase , även känd som PascalCase , för de flesta identifierare. För parametrar och variabler rekommenderas att du använder lowerCamelCase ), som är en allmän konvention för .NET-språk [36] . Microsoft rekommenderar också att du inte använder typprefixtips (även känd som ungersk notation [37] . Istället för att använda ungersk notation, rekommenderas att du avslutar namnet med basklassens namn: LoginButtonistället BtnLoginför [38] .
Objective-C har en allmän programmeringsstil med rötter i Smalltalk .
Entiteter på toppnivå, inklusive klasser, protokoll, kategorier, såväl som C-konstruktioner som används i Objective-C-program, såsom globala variabler och funktioner, finns i UpperCamelCase med ett kort prefix med versaler som anger namnutrymmet, t.ex. NSString , UIAppDelegate . NSApp eller CGRectMake . Konstanter kan valfritt föregås av ett gement "k", såsom kCFBooleanTrue .
Objektvariabler använder lowerCamelCase med ett understreck som prefix, som _delegate och _tableView .
Metodnamnen använder flera kolonseparerade lowerCamelCase-delar som separerar argumenten, till exempel: application: didFinishLaunchingWithOptions: , stringWithFormat: och isRunning .
Språken Pascal, Modula-2 och Oberon använder vanligtvis identifierare Capitalizedeller UpperCamelCaseför program, moduler, konstanter, typer och procedurer och lowerCamelCaseidentifierare lowercaseeller lowerCamelCaseför matematiska konstanter, variabler, formella parametrar och funktioner [39] . Medan vissa dialekter stöder understreck och dollartecken i identifierare, är orm- och makroskiften troligen begränsade till användning i externa API:er [40] .
Perl tar några regler från sitt C-arv. Variable och lokalt omfångade underprogramnamn skrivs med gemener med infix understreck. Subrutiner och variabler som ska behandlas som privata har ett understreck. Paketvariabler är inneslutna i en rubrik. Alla deklarerade konstanter är versaler. Paketnamn skrivs med versaler, förutom pragmer som strictoch mro, som mroskrivs med gemener [41] [42] .
PHP - rekommendationer finns i PSR-1 (PHP-standardrekommendation 1) och PSR-12 [43] . Enligt PSR-1 måste klassnamn vara i PascalCase, klasskonstanter måste vara i MACRO_CASE och metodnamn måste vara i camelCase [44] .
Python och Ruby rekommenderas UpperCamelCaseför klassnamn, CAPITALIZED_WITH_UNDERSCORESför konstanter och lowercase_separated_by_underscoresför andra namn.
I Python, om ett namn ska vara " privat " inom en modul, rekommenderas det att det börjar med ett enda understreck. Namn kan också sluta med ett enda understreck för att förhindra konflikt med Python-sökord. Det dubbla understrecksprefixet, å andra sidan, förvränger den externa representationen av klassmedlemsnamn: till exempel i en klass kommer FooBaren metod __booutanför klassen att vara synlig som _FooBar__boo. Namn som både börjar och slutar med ett dubbelt understreck är reserverade för "magiska namn" som spelar en speciell roll i Python (t.ex. , __init__, __import__) __file__[ 45] .
Även om det inte finns någon officiell stilguide för R , sätter den tidyverse stilguiden från R-gurun Hadley Wickham standarden för de flesta användare [46] . Den här guiden rekommenderar att du undviker specialtecken i filnamn och att du endast använder siffror, bokstäver och understreck för variabel- och funktionsnamn, till exempel fit_models. R.
Raku följer mer eller mindre samma regler som Perl, förutom att Raku tillåter interna bindestreck och apostrof (enkla citattecken) så länge de alltid följs av bokstäver. Således kan kebab -case användas i Raku : till exempel, fish-foodoch don't-do-thatär giltiga identifierare [47] .
Rust rekommenderar UpperCamelCasestruct, trait, enum och enum för typalias och variantnamn, SCREAMING_SNAKE_CASEför konstanter eller statiska variabler och snake_caseför variabel-, funktions- och strukturnamn [48] .
Swift ändrar sina namnkonventioner med varje enskild release. Den stora uppdateringen av Swift 3.0 stabiliserade dock namnkonventionerna för lowerCamelCasevariabler och funktionsdeklarationer. Konstanter definieras vanligtvis av uppräknade typer eller konstanta parametrar, som också skrivs på samma sätt. Deklarationer av klasser och andra typer av objekt är UpperCamelCase.
Sedan Swift 3.0 har tydliga namngivningsriktlinjer för språket formulerats med målet att standardisera namnkonventioner och API-deklarationer för alla tredje parts API:er [49] .