Naming Conventions

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 __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?
    Android resource naming convention. Source: Mols 2016.
    Android resource naming convention. Source: Mols 2016.

    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?
    Common naming conventions in Java. Source: Kumar 2017.
    Common naming conventions in Java. Source: Kumar 2017.

    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
Apps Hungarian notation applied in Selenium-Java. Source: Pragmatic Test Labs 2018.
Apps Hungarian notation applied in Selenium-Java. Source: Pragmatic Test Labs 2018.

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
A variety of conventions across R projects. Source: Bååth 2012, fig. 1.
A variety of conventions across R projects. Source: Bååth 2012, fig. 1.

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.

References

  1. Abrams, Brad. 2004. "History around Pascal Casing and Camel Casing." MSDN Blog, Microsoft, February 03. Accessed 2019-02-04.
  2. Atomic Object. 2014. "OO Naming Conventions." Lecture Notes on Object-Oriented Programming, Atomic Object, November 05. Accessed 2019-02-04.
  3. Bååth, Rasmus. 2012. "The State of Naming Conventions in R." The R Journal, vol. 4/2, December. Accessed 2019-02-05.
  4. Capitalize My Title. 2019. "Camel and Snake Case Converter." Accessed 2019-02-04.
  5. ETL. 2014. "Naming conventions for instance, local and parameter variables." Software Engineering, StackExchange, November 30. Accessed 2019-02-05.
  6. Emmanuel, Ohans. 2018. "CSS Naming Conventions that Will Save You Hours of Debugging." freeCodeCamp, January 17. Accessed 2019-02-04.
  7. Fowler, Martin. 2009. "TwoHardThings." July 14. Accessed 2019-02-04.
  8. GNU. 2018. "The GNU Awk User’s Guide." Edition 4.2. Accessed 2019-02-04.
  9. Jolas. 2017. "Meaningful Names - A Dimension of writing Clean Code." MindOrks, on Medium, May 24. Accessed 2019-02-05.
  10. Kotlin Docs. 2019. "Coding Conventions." Kotlin Docs, January 30. Accessed 2019-02-04.
  11. Kumar, Abhishek. 2017. "Advantage of Naming Conventions in Java." Blog, SwiftLogic, June 27. Accessed 2019-02-04.
  12. Manu, Dasagriva. 2018. "Python Naming Conventions — The 10 Points You Should Know." Medium, March 12. Accessed 2019-02-04.
  13. McFarlin, Tom. 2013. "WordPress Coding Standards: Naming Conventions & Function Arguments." Envato Tuts+, June 06. Accessed 2019-02-04.
  14. Microsoft Docs. 2008. "General Naming Conventions." .NET, Microsoft, October 22. Accessed 2019-02-04.
  15. Mols, Jeroen. 2016. "A successful XML naming convention." Blog, March 07. Accessed 2019-02-04.
  16. Pragmatic Test Labs. 2018. "Coding-convention for Selenium-Java." Pragmatic Test Labs, March 05. Accessed 2019-02-04.
  17. Shaun. 2016. "Letter Casing in Names of Imported NodeJS Modules." Scion of Bytes, December 01. Accessed 2019-02-04.
  18. Sheryl. 2014. "Item 56: Adhere to generally accepted naming conventions." Programering, May 26. Accessed 2019-02-04.
  19. Sider. 2018. "5 PHP Coding Standards You Will Love and How to Use them." Sider, on Medium, April 25. Accessed 2019-02-04.
  20. Spolsky, Joel. 2005. "Making Wrong Code Look Wrong." Joel on Software, May 11. Accessed 2019-02-05.
  21. Subotic, Petar. 2011. "Benefits of Naming Conventions." September 17. Accessed 2019-02-04.
  22. Tan, Richard. 2018. "The art of naming variables." Hacker Noon, August 07. Accessed 2019-02-05.
  23. Vogel, Peter. 2013. "Creating Useful Naming Conventions: Business Considerations." Visual Studio Magazine, December 20. Accessed 2019-02-04.
  24. Way, Jeffrey. 2010. "9 Confusing Naming Conventions for Beginners." Envato Tuts+, October 22. Accessed 2019-02-05.
  25. Wikipedia. 2018. "Hungarian notation." Wikipedia, November 22. Accessed 2019-02-04.
  26. Wikipedia. 2019a. "Naming convention (programming)." Wikipedia, January 23. Accessed 2019-02-04.
  27. Wikipedia. 2019b. "Letter case." Wikipedia, January 22. Accessed 2019-02-04.
  28. Wikipedia. 2019c. "Snake case." Wikipedia, January 20. Accessed 2019-02-04.
  29. Wikipedia. 2019d. "Camel case." Wikipedia, January 18. Accessed 2019-02-04.
  30. Zahn, Martin. 2003. "Naming Conventions for .NET / C# Projects." Akadia, March 20. Accessed 2019-02-04.
  31. gbjbaanb. 2013. "Java naming conventions vs. C++/C naming conventions." Software Engineering, StackExchange, July 20. Accessed 2019-02-04.
  32. van Rossum, Guido, Barry Warsaw, and Nick Coghlan. 2001. "PEP 8 -- Style Guide for Python Code" Python.org. July 5. Accessed 2019-02-05.

Further Reading

  1. Tan, Richard. 2018. "The art of naming variables." Hacker Noon, August 07. Accessed 2019-02-05.
  2. Way, Jeffrey. 2010. "9 Confusing Naming Conventions for Beginners." Envato Tuts+, October 22. Accessed 2019-02-05.
  3. Jolas. 2017. "Meaningful Names - A Dimension of writing Clean Code." MindOrks, on Medium, May 24. Accessed 2019-02-05.
  4. Spolsky, Joel. 2005. "Making Wrong Code Look Wrong." Joel on Software, May 11. Accessed 2019-02-05.
  5. Piater, Justus. 2005. "A Guide to Coding Style." Dept. of Electrical Engineering and Computer Science, Montefiore Institute, January 14. Accessed 2019-02-04.
  6. Pollentier, Jason. 2018. "Language Naming Conventions in Programming: It's All in the Context." Revelry, July 04. Accessed 2019-02-04.

Article Stats

Author-wise Stats for Article Edits

Author
No. of Edits
No. of Chats
DevCoins
Avatar of user mohanjo mohanjo
3
0
6187
Avatar of user arvindpdmn arvindpdmn
2
0
114
Avatar of user devbot5S devbot5S
1
0
32
DevCoins due to articles, chats, their likes and article hits are included.
1583
Words
3
Authors
6
Edits
0
Chats
20
Likes
88K
Hits

Cite As

Devopedia. 2022. "Naming Conventions." Version 6, February 15. Accessed 2024-06-25. https://devopedia.org/naming-conventions
Contributed by
3 authors

Last updated on
2022-02-15 11:52:46
design languages conventions

See Also