naming convention (programming) in computer programming a naming convention is a set of rules for choosing the character sequence to be used for identifiers which denote variables types functions and other entities in source code and documentation reasons for using a naming convention as opposed to allowing programmers to choose any character sequence include the following to reduce the effort needed to read and understand source code to enable code reviews to focus on more important issues than arguing over syntax and naming standards to enable code quality review tools to focus their reporting mainly on significant issues other than syntax and style preferences the choice of naming conventions can be an enormously controversial issue with partisans of each holding theirs to be the best and others to be inferior colloquially this is said to be a matter of dogma many companies have also established their own set of conventions potential benefits some of the potential benefits that can be obtained by adopting a naming convention include the following to provide additional information ie metadata about the use to which an identifier is put to help formalize expectations and promote consistency within a development team to enable the use of automated refactoring or search and replace tools with minimal potential for error to enhance clarity in cases of potential ambiguity to enhance the aesthetic and professional appearance of work product for example by disallowing overly long names comical or cute names or abbreviations to help avoid naming collisions that might occur when the work product of different organizations is combined see also namespaces to provide meaningful data to be used in project handovers which require submission of program source code and all relevant documentation to provide better understanding in case of code reuse after a long interval of time challenges the choice of naming conventions and the extent to which they are enforced is often a contentious issue with partisans holding their viewpoint to be the best and others to be inferior moreover even with known and welldefined naming conventions in place some organizations may fail to consistently adhere to them causing inconsistency and confusion these challenges may be exacerbated if the naming convention rules are internally inconsistent arbitrary difficult to remember or otherwise perceived as more burdensome than beneficial readability wellchosen identifiers make it significantly easier for developers and analysts to understand what the system is doing and how to fix or extend the source code to apply for new needs for example although the statement a b c is syntactically correct its purpose is not evident contrast this with weeklypay hoursworked hourlypayrate which implies the intent and meaning of the source code at least to those familiar with the context of the statement common elements the exact rules of a naming convention depend on the context in which they are employed nevertheless there are several common elements that influence most if not all naming conventions in common use today length of identifiers fundamental elements of all naming conventions are the rules related to identifier length ie the finite number of individual characters allowed in an identifier some rules dictate a fixed numerical bound while others specify less precise heuristics or guidelines identifier length rules are routinely contested in practice and subject to much debate academically some considerations shorter identifiers may be preferred as more expedient because they are easier to type extremely short identifiers such as i or j are very difficult to uniquely distinguish using automated search and replace tools longer identifiers may be preferred because short identifiers cannot encode enough information or appear too cryptic longer identifiers may be disfavored because of visual clutter it is an open research issue whether some programmers prefer shorter identifiers because they are easier to type or think up than longer identifiers or because in many situations a longer identifier simply clutters the visible code and provides no perceived additional benefit brevity in programming could be in part attributed to early linkers which required variable names to be restricted to 6 characters to save memory a later advance allowed longer variable names to be used for human comprehensibility but where only the first few characters were significant in some versions of basic such as trs80 level 2 basic long names were allowed but only the first two letters were significant this feature permitted erroneous behaviour that could be difficult to debug for example when names such as value and vat were used and intended to be distinct early source code editors lacking autocomplete early lowresolution monitors with limited line length eg only 80 characters much of computer science originating from mathematics where variable names are traditionally only a single letter letter case and numerals some naming conventions limit whether letters may appear in uppercase or lowercase other conventions do not restrict letter case but attach a welldefined interpretation based on letter case some naming conventions specify whether alphabetic numeric or alphanumeric characters may be used and if so in what sequence multipleword identifiers a common recommendation is use meaningful identifiers a single word may not be as meaningful or specific as multiple words consequently some naming conventions specify rules for the treatment of compound identifiers containing more than one word as most programming languages do not allow whitespace in identifiers a method of delimiting each word is needed to make it easier for subsequent readers to interpret which characters belong to which word historically some early languages notably fortran 1955 and algol 1958 allowed spaces within identifiers determining the end of identifiers by context this was abandoned in later languages due to the difficulty of tokenization it is possible to write names by simply concatenating words and this is sometimes used as in mypackage for java package names though legibility suffers for longer terms so usually some form of separation is used delimiterseparated words one approach is to delimit separate words with a nonalphanumeric character the two characters commonly used for this purpose are the hyphen and the underscore eg the twoword name two words would be represented as twowords or twowords the hyphen is used by nearly all programmers writing cobol 1959 forth 1970 and lisp 1958 it is also common in unix for commands and packages and is used in css by contrast languages in the fortranalgol tradition notably languages in the c and pascal families used the hyphen for the subtraction infix operator and did not wish to require spaces around it as freeform languages preventing its use in identifiers an alternative is to use underscores this is common in the c family including python with lowercase words being found for example in the c programming language 1978 and has come to be known as snake case underscores with uppercase as in uppercase are commonly used for c preprocessor macros hence known as macrocase and for environment variables in unix such as bashversion in bash sometimes this is humorously referred to as screamingsnakecase letter caseseparated words see also letter case special case styles another approach is to indicate word boundaries using medial capitalization called camelcase pascal case and many other names thus rendering two words as either twowords or twowords this convention is commonly used in pascal java c and visual basic treatment of acronyms in identifiers eg the xml and http in xmlhttprequest varies some dictate that they be lowercased eg xmlhttprequest to ease typing and readability whereas others leave them uppercased eg xmlhttprequest for accuracy metadata and hybrid conventions some naming conventions represent rules or requirements that go beyond the requirements of a specific project or problem domain and instead reflect a greater overarching set of principles defined by the software architecture underlying programming language or other kind of crossproject methodology hungarian notation perhaps the most wellknown is hungarian notation which encodes either the purpose apps hungarian or the type systems hungarian of a variable in its name for example the prefix sz for the variable szname indicates that the variable is a nullterminated string positional notation a style used for very short 8 characters and less could be lcciil01 where lc would be the application letters of credit c for cobol iil for the particular process subset and the 01 a sequence number this sort of convention is still in active use in mainframes dependent upon jcl and is also seen in the 83 maximum 8 characters with period separator followed by 3 character file type msdos style composite word scheme of language ibms of language was documented in an ims information management system manual it detailed the primemodifierclass word scheme which consisted of names like custactno to indicate customer account number prime words were meant to indicate major entities of interest to a system modifier words were used for additional refinement qualification and readability class words ideally would be a very short list of data types relevant to a particular application common class words might be no number id identifier txt text amt amount qty quantity fl flag cd code w work and so forth in practice the available class words would be a list of less than two dozen terms class words typically positioned on the right suffix served much the same purpose as hungarian notation prefixes the purpose of class words in addition to consistency was to specify to the programmer the data type of a particular data field prior to the acceptance of boolean two values only fields fl flag would indicate a field with only two possible values languagespecific conventions actionscript adobes coding conventions and best practices suggests naming standards for actionscript that are mostly consistent with those of ecmascript the style of identifiers is similar to that of java ada in ada the only recommended style of identifiers is mixedcasewithunderscores c and c in c and c keywords and standard library identifiers are mostly lowercase in the c standard library abbreviated names are the most common eg isalnum for a function testing whether a character is alphanumeric while the c standard library often uses an underscore as a word separator eg outofrange identifiers representing macros are by convention written using only uppercase letters and underscores this is related to the convention in many programming languages of using alluppercase identifiers for constants names containing double underscore or beginning with an underscore and a capital letter are reserved for implementation compiler standard library and should not be used eg reserved or reserved this is superficially similar to stropping but the semantics differ the underscores are part of the value of the identifier rather than being quoting characters as is stropping the value of foo is foo which is reserved not foo but in a different namespace go in go the convention is to use mixedcaps or mixedcaps rather than underscores to write multiword names java in java naming conventions for identifiers have been established and suggested by various java communities such as sun microsystems etc a sample of naming conventions set by sun microsystems are listed below where a name in camelcase is one composed of a number of words joined without spaces with each words initial letter in capitals for example camelcase identifier type rules for naming examples classes class names should be nouns in uppercamelcase with the first letter of every word capitalised use whole words avoid acronyms and abbreviations unless the abbreviation is much more widely used than the long form such as url or html class raster class imagesprite methods methods should be verbs in lowercamelcase or a multiword name that begins with a verb in lowercase that is with the first letter lowercase and the first letters of subsequent words in uppercase run runfast getbackground variables local variables instance variables and class variables are also written in lowercamelcase variable names should not start with underscore or dollar sign characters even though both are allowed this is in contrast to other coding conventions that state that underscores should be used to prefix all instance variables variable names should be short yet meaningful the choice of a variable name should be mnemonic that is designed to indicate to the casual observer the intent of its use onecharacter variable names should be avoided except for temporary throwaway variables common names for temporary variables are i j k m and n for integers c d and e for characters int i char c float mywidth constants constants should be written in uppercase characters separated by underscores constant names may also contain digits if appropriate but not as the first character static final int maxparticipants 10 java compilers do not enforce these rules but failing to follow them may result in confusion and erroneous code for example widgetexpand and widgetexpand imply significantly different behaviours widgetexpand implies an invocation to method expand in an instance named widget whereas widgetexpand implies an invocation to static method expand in class widget one widely used java coding style dictates that uppercamelcase be used for classes and lowercamelcase be used for instances and methods recognising this usage some ides such as eclipse implement shortcuts based on camelcase for instance in eclipses content assist feature typing just the uppercase letters of a camelcase word will suggest any matching class or method name for example typing npe and activating content assist could suggest nullpointerexception initialisms of three or more letters are camelcase instead of uppercase eg parsedbmxmlfromipaddress instead of parsedbmxmlfromipaddress one may also set the boundary at two or more letters eg parsedbmxmlfromipaddress javascript the builtin javascript libraries use the same naming conventions as java data types and constructor functions use upper camel case regexp typeerror xmlhttprequest domobject and methods use lower camel case getelementbyid getelementsbytagnamens createcdatasection in order to be consistent most javascript developers follow these conventions see also douglas crockfords conventions lisp common practice in most lisp dialects is to use dashes to separate words in identifiers as in withopenfile and makehashtable dynamic variable names conventionally start and end with asterisks mapwalls constants names are marked by plus signs mapsize net microsoft net recommends uppercamelcase for most identifiers lowercamelcase is recommended for parameters and variables and is a shared convention for the net languages objectivec objectivec has a common coding style that has its roots in smalltalk toplevel entities including classes protocols categories as well as c constructs that are used in objectivec programs like global variables and functions are in uppercamelcase with a short alluppercase prefix denoting namespace like nsstring uiappdelegate nsapp or cgrectmake constants may optionally be prefixed with a lowercase letter k like kcfbooleantrue instance variables of an object use lowercamelcase prefixed with an underscore like delegate and tableview method names use multiple lowercamelcase parts separated by colons that delimit arguments like applicationdidfinishlaunchingwithoptions stringwithformat and isrunning pascal modula2 and oberon wirthian languages pascal modula2 and oberon generally use capitalized or uppercamelcase identifiers for programs modules constants types and procedures and lowercase or lowercamelcase identifiers for math constants variables formal parameters and functions perl perl takes some cues from its c heritage for conventions locally scoped variables and subroutine names are lowercase with infix underscores subroutines and variables meant to be treated as private are prefixed with an underscore package variables are title cased declared constants are all caps package names are camel case excepting pragmataeg strict and mrowhich are lowercase perl 6 perl 6 follows more or less the same conventions as perl except that it allows an infix hyphen or an apostrophe or single quote within an identifier but not two in a row provided that it is followed by an alphabetic character perl 6 programmers thus often use kebab case in their identifiers for example fishfood and dontdothat are valid identifiers php php recommendations are contained in psr1 php standard recommendation 1 and psr2 python and ruby python and ruby both recommend uppercamelcase for class names capitalizedwithunderscores for constants and lowercaseseparatedbyunderscores for other names in python if a name is intended to be private it is prefixed by an underscore private variables are only enforced by convention in python names can also be suffixed with an underscore to prevent conflict with python keywords prefixing with double underscores changes behaviour in classes with regard to name mangling prefixing and suffixing with double underscores are reserved for magic names which fulfill special behaviour in python objects rust rust recommends uppercamelcase for type aliases and struct trait enum and enum variant names capitalizedwithunderscores for constants or statics and lowercaseseparatedbyunderscores for other names swift swift has shifted its naming conventions with each individual release however a major update with swift 30 stabilised the naming conventions for lowercamelcase across variables and function declarations constants are usually defined by enum types or constant parameters that are also written this way class and other object type declarations are uppercamelcase as of swift 30 there have been made clear naming guidelines for the language in an effort to standardise the api naming and declaration conventions across all third party apis categorynaming conventions checkstyle coding conventions list of tools for static code analysis namespace naming convention sigil computer programming american name society promotes onomastics the study of names and naming practices both in the united states and abroad codingguidelinescom has a pdf that uses linguistics and psychology to attempt a costbenefit analysis of identifier naming issues 