Programming Naming Convention
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 issues more important than syntax and naming standards.
- To enable code quality review tools to focus their reporting mainly on significant issues other than syntax and style preferences.
flatcase
Simply typing out your variables in lower case is called flat case. No requirement for hyphens or underscores, or even separating out each word with a capital.
camelCase
Camel case is the practice of writing phrases without spaces or punctuation, indicating the separation of words with a single capitalized letter, and the first word starting with either case.
PascalCase
also known as UpperCamelCase or StudlyCase ; is a naming convention in which the first letter of each word in a compound word is capitalized.
Software developers often use PascalCase when writing source code to name functions, classes, and other objects. PascalCase is similar to camelCase, except the first letter in PascalCase is always capitalized.
snake_case
refers to the style of writing in which each space is replaced by an underscore ( _ ) character, and the first letter of each word written in lowercase.It is a commonly used for variable and subroutine names, and for filenames.
One study has found that readers can recognize snake case values more quickly than camel case
SCREAMING_SNAKE_CASE
also known as MACRO_CASE, CONSTANT_CASE; refers to the style of writing in which each space is replaced by an underscore (_) character, and the first letter of each word written in Uppercase.
camel_Snake_Case
without spaces or punctuation, indicating the separation of words with underscore ( _ ) capitalized letter, and the first word starting with either case.
Pascal_Snake_Case
without spaces or punctuation, indicating the separation of words with underscore ( _ ) which the first letter of each word in a compound word is capitalized.
kebab-case
Similar to snake case, above, except hyphens (-) rather than underscores (_) are used to replace spaces. It is also known as spinal case, param case, Lisp case in reference to the Lisp programming language, or dash case (or illustratively as kebab-case).
TRAIN-CASE
if kebab-case, every word is uppercase , the style is known as train case (TRAIN-CASE) also known as COBOL-CASE, SCREAMING-KEBAB-CASE
Train-Case
if kebab-case, every word is capitalized, the style is known as train case (Train-Case) also known as HTTP-Header-Case.
dot.case
Similar to snake case, above, except hyphens (-) rather than dot ( . ) are used to replace spaces
How to creating Good Names in our code?
Robert C. Martin : Names are everywhere in software. We name our variables, our functions, our arguments, classes, and packages. We name our source files and the directories that contain them. We name our jar files and war files and ear files. We name and name and name. Because we do so much of it, we’d better do it well.
What follows are 15 simple rules for creating good names.
1- Use Intention-Revealing Names
It is easy to say that names should reveal intent. What we want to impress upon you is that we are serious about this. Choosing good names takes time but saves more than it takes. So take care with your names and change them when you find better ones. Everyone who reads your code (including you) will be happier if you do.
2- Avoid Disinformation
Programmers must avoid leaving false clues that obscure the meaning of code. We should avoid words whose entrenched meanings vary from our intended meaning.
3- Make Meaningful Distinctions
Programmers create problems for themselves when they write code solely to satisfy a compiler or interpreter.For example, because you can’t use the same name to refer to two different things in the same scope, you might be tempted to change one name in an arbitrary way.
4- Use Pronounceable Names
Humans are good at words. A significant part of our brains is dedicated to the concept of words. And words are, by definition, pronounceable.It would be a shame not to take advantage of that huge portion of our brains that has evolved to deal with spoken language. So make your names pronounceable.
5- Use Searchable Names
Single-letter names and numeric constants have a particular problem in that they are not easy to locate across a body of text.
6- Avoid Encodings
We have enough encodings to deal with without adding more to our burden. Encoding type or scope information into names simply adds an extra burden of deciphering.
7- Member Prefixes
You also don’t need to prefix member variables with m_ anymore. Your classes and functions should be small enough that you don’t need them. And you should be using an editing environment that highlights or colorizes members to make them distinct.
8- Avoid Mental Mapping
Readers shouldn’t have to mentally translate your names into other names they already know. This problem generally arises from a choice to use neither problem domain terms nor solution domain terms.
9- Don’t Be Cute
If names are too clever, they will be memorable only to people who share the author’s sense of humor, and only as long as these people remember the joke.Will they know what the function named `HolyHandGrenade` is supposed to do? Sure, it’s cute, but maybe in this case `DeleteItems` might be a better name.Choose clarity over entertainment value.
10- Pick One Word per Concept
Pick one word for one abstract concept and stick with it. For instance, it’s confusing to have fetch, retrieve, and get as equivalent methods of different classes. How do you remember which method name goes with which class? Sadly, you often have to remember which company, group, or individual wrote the library or class in order to remember which term was used. Otherwise, you spend an awful lot of time browsing through headers and previous code samples.
11- Don’t Pun
Avoid using the same word for two purposes. Using the same term for two different ideas is essentially a pun.If you follow the “one word per concept” rule, you could end up with many classes that have, for example, an add method. As long as the parameter lists and return values of the various add methods are semantically equivalent, all is well.
12- Use Solution Domain Names
Remember that the people who read your code will be programmers. So go ahead and use computer science (CS) terms, algorithm names, pattern names, math terms, and so forth. It is not wise to draw every name from the problem domain because we don’t want our coworkers to have to run back and forth to the customer asking what every name means when they already know the concept by a different name.
13- Use Problem Domain Names
When there is no “programmer-eese” for what you’re doing, use the name from the problem domain. At least the programmer who maintains your code can ask a domain expert what it means.
Separating solution and problem domain concepts is part of the job of a good programmer and designer. The code that has more to do with problem domain concepts should have names drawn from the problem domain.
14- Add Meaningful Context
There are a few names which are meaningful in and of themselves — most are not. Instead, you need to place names in context for your reader by enclosing them in well-named classes, functions, or namespaces. When all else fails, then prefixing the name may be necessary as a last resort.
15- Don’t Add Gratuitous Context
In an imaginary application called “Gas Station Deluxe,” it is a bad idea to prefix every class with GSD. Frankly, you are working against your tools. You type G and press the completion key and are rewarded with a mile-long list of every class in the system. Is that wise? Why make it hard for the IDE to help you?
References
Clean Code: A Handbook of Agile Software Craftsmanship by Robert C. Martin
