# Naming Conventions

## Summary


In general, code is written once but read multiple times, by others in the project team or even those from other teams. Readability is therefore important. Readability is nothing more than figuring out what the code does in less time. 

Among the many best practices of coding, is the way variables, functions, classes and even files are named in a project. A common naming convention that everyone agrees to follow must be accompanied by consistent usage. This will result in developers, reviewers and project managers communicate effectively with respect to what the code does. 

While there are well-established naming conventions, there's no single one that fits all scenarios. Each programming language recommends its own convention. Each project or organization may define it's own convention.

## Discussion

### Why should we have a naming convention and what are its advantages?

Naming conventions are probably not important if the code is written by a single developer, who's also the sole maintainer. However, typical real-world projects are developed and maintained by teams of developers. Particularly in the context of open source projects, code is shared, updated and merged by many individuals across organizations and geographies. Naming conventions are therefore important.

Naming conventions result in improvements in terms of "four Cs": communication, code integration, consistency and clarity. The idea is that "code should explain itself". At code reviews, we can focus on important design decisions or program flow rather than argue about naming. 

Naming conventions lead to predictability and discoverability. A common naming convention, coupled with a consistent project structure, makes it easier to find files in a project.  

In short, naming convention is so important that Phil Karlton is said to have said, 

> There are only two hard things in Computer Science: cache invalidation and naming things.


### What are some common naming conventions used in programming?

Among the common ones are the following:

    + **Camel Case**: First letter of every word is capitalized with no spaces or symbols between words. Examples: `UserAccount`, `FedEx`, `WordPerfect`. A variation common in programming is to start with a lower case: `iPad`, `eBay`, `fileName`, `userAccount`. Microsoft uses the term Camel Case to refer strictly to this variation.
    + **Pascal Case**: Popularized by Pascal programming language, this is a subset of Camel Case where the word starts with uppercase. Thus, `UserAccount` is in Pascal Case but not `userAccount`.
    + **Snake Case**: Words within phrases or compound words are separated with an underscore. Examples: `first_name`, `error_message`, `account_balance`.
    + **Kebab Case**: Like Snake Case, but using hyphens instead. Examples: `first-name`, `main-section`.
    + **Screaming Case**: This refers to names in uppercase. Examples: `TAXRATE`, `TAX_RATE`.
    + **Hungarian Notation**: Names start with a lowercase prefix to indicate intention. Rest of the name is in Pascal Case. It comes in two variants: (a) *Systems Hungarian*, where prefix indicates data type; (b) *Apps Hungarian*, where prefix indicates logical purpose. Examples: `strFirstName`, `arrUserNames` for Systems; `rwPosition`, `pchName` for Apps.

### What are the categories of naming conventions?

It's common to categorize a naming convention as one of these:

    + **Typographical**: This relates to the use of letter case and symbols such as underscore, dot and hyphen.
    + **Grammatical**: This relates to the semantics or the purpose. For example, classes should be nouns or noun phrases to identify the entity; methods and functions should be verbs or verb phrases to identify action performed; annotations can be any part of speech; interfaces should be adjectives.Grammatical conventions are less important for variable names or instance properties. They are more important for classes, interfaces and methods that are often exposed as APIs. 


### What's the typical scope of a naming convention?

Naming convention is applicable to constants, variables, functions, modules, packages and files. In object-oriented languages, it's applicable to classes, objects, methods and instance variables. 

With regard to scope, global names may have a different convention compared to local names; such as, Pascal Case for globals: `Optind` rather than `optind` in gawk. Private or protected attributes may be named differently: `_secret` or `&lowbar;&lowbar;secret` rather than `secret`. Some may want to distinguish local variables from method arguments using prefixes. Python's PEP8 doesn't give a naming convention to tell apart class attributes from instance attributes but other languages or projects might define such a convention. 

In general, use nouns for classes, verbs for functions, and names that show purpose for variables, attributes and arguments. Avoid (Systems) Hungarian notation in dynamically typed languages since data types can change. Use lower Camel Case for variables and methods. Use Pascal Case for classes and their constructors. Use Screaming Case for constants. 


### What word separators are used in naming conventions and who's using what?

With Camel Case and Pascal Case, there are no word separators. Readability is achieved by capitalizing the first letter of each word. Languages adopting this include Pascal, Modula, Java and .NET. 

With Snake Case, underscore is the separator. This practice is common in Python, Ruby, C/C++ standard libraries, and WordPress. 

With Kebab Case, hyphen is the separator. Languages using this include COBOL, Lisp, Perl 6, and CSS. Since hyphen in many languages is used for subtraction, Kebab Case is less common than Snake Case. 

It's common for a language to adopt different case styles for different contexts. For example, a PHP convention named PSR-1 adopts the following: `PascalCase` for class names, `UPPER_SNAKE_CASE` for class variables and `camelCase` for method names. 


### Where can I find published naming conventions for different languages?

Python defines its naming convention as part of PEP8. Beginners can read a summary. 

Rust's conventions are summarized in its official documentation. It uses Camel Case for type constructs and Snake Case for value constructs.

Google offers it's own naming convention for Java and for R.

Kotlin follows Java's conventions and they're summarized in its documentation. 

.NET naming conventions are available online. 

Resources in Android projects are defined in XML but without namespaces. This makes it difficult to find stuff. One suggested XML naming convention solves this problem. 

For user interface design and names in CSS, BEM Methodology is worth studying. 


### Are there exceptions to following a common naming convention?

Following a common naming convention is beneficial. However, it may be okay to relax the rules in some cases. When a name is highly localized, lacks business context or used within a few lines of code, it may be acceptable to use a short name (`fi` rather than `CustAcctFileInfo`). 

When a project is written in multiple languages, it's not possible to have a single naming convention. For each language, adopt the naming convention prevalent in that language. Another example is when you're using a third-party library. Follow their convention for consistency and readability. 

Ultimately, naming conventions should not be enforced blindly. We should be sensitive to the context of use. This is partly because IDEs come to the aid of developers. They can highlight the name in all places it occurs. The practice of prefixing member and static variables with `m` and `s` respectively is also not in favour since IDEs colour them differently. 


### Could you give some tips to create a naming convention?

Without being exhaustive here are some things to consider:

    + Reveal intentions: `fileName` is better `f`; `maxPugs` is better than `pugs`.
    + Make distinctions: `moneyInDollars` is better than `money`.
    + Put the distinguishing aspect first: `dollarMoney` and `rupeeMoney` are better than `moneyInDollars` and `moneyInRupees`.
    + Easy to pronounce: `timeStamp` is better than `ts`.
    + Verbs for functions: `getName()` and `isPosted()` are good; `hasWeight()` or `isMale()` when boolean values are returned; `toDollars()` for conversions.
    + One word, one concept: `fetch`, `retrieve`, `get` all imply the same thing: use one of them consistently.
    + Relate to business context: `AddCustomer` is better than `IncrementCounter`.
    + Use shortforms judiciously: `PremiumCust` may be used over `PremiumCustomer` to emphasize "Premium"; but `fn` is not a good substitute for `fileName`.
    + Describe content rather than storage: `user_info` is better than `user_list`.
    + Plurals for containers: `fruitNames` is better than `fruit` for an array of fruit names.
    + Describe content rather than presentational aspects: in CSS, for example, `main-section` is better than `middle-left-and-then-a-little-lower` as identifier name.


## Milestones

1813

An early use of Camel Case, more formally called **medial capitals**, starts in chemistry. Swedish chemist Jacob Berzelius invents it to represent chemical formulae. For example, Sodium Chloride is easier to read as `NaCl` than `Nacl`. 

1960

The use of **Snake Case** can be traced to the late 1960s. In the 1970s, it's used in C language, while Pascal uses what is later called **Pascal Case**. However, the name Snake Case itself is coined in the early 2000s. 

1970

The 1970s is when **Camel Case** started becoming common in the world of computer programming. However, the name itself is coined years later (in 1995) and is attributed to Newton Love. 

1980

In the 1980s, Charles Simonyi, a Hungarian working at Microsoft, invents the notation of using lowercase prefixes to names to indicate what the name referred to. Thus is born (Apps) **Hungarian Notation**. Unfortunately, some mistake Simonyi's idea and use prefixes to indicate data types. This is born Systems Hungarian. While Apps Hungarian is useful, Systems Hungarian is not, particularly in type safe languages. When Microsoft start working on .NET in the late 1990s, they recommend not using Hungarian notation. 

Dec  
2012

R language doesn't officially specify a naming convention. Therefore multiple conventions exist. An analysis of 2668 R packages downloaded from CRAN shows a lack of consistency. In fact, 28% of packages use three or more conventions.