Every programmer should be aware of the best practices to be followed while writing a piece of code. Good code is self-explanatory, readable, optimized and easy to maintain. Any piece of code should be human-readable and as easy to understand as a story. Naming conventions play a major role in this.
Below are certain norms which should be considered while naming a variable,
|
No.
|
Variable name should be |
|
1
|
Intention revealing. The reader should understand the usage of the variable from the name; e.g. var isValidName = false is more appropriate than var flag = false
|
|
2
|
Meaningfully Distinct
Name. It shouldn’t be similar; e.g. productInfo and productData are confusing names for two different variables
|
|
3
|
Searchable. The reader should be able to search the variable easily in IDE; e.g., if the programmer used i (instead of index), searching the variable will be a pain, as the whole code will have the letter i in different names.
|
|
4
|
Pronounceable. The reader should be able to pronounce it; e.g., var genymdhs is just gibberish while generationTimeStamp is meaningful and pronounceable
|
|
5
|
No Encoding. Don’t add context; type in the name. (e.g. Hungarian notation is a practice of adding variable type in the name)
e.g userNameString
|
|
6
|
Easy to Differentiate. Use names that can be easily differentiated; e.g., controllerForEfficientHandlingOfUserName and controllerForEfficientStorageOfName are difficult to differentiate.
handlingOfUserName and storageOfUserName can be a replacement for the above names.
|
|
7
|
Use Camel Case Naming Convention; e.g., var userName
|
Below are certain norms which should be considered while naming a method.
|
No.
|
Norms
|
|
1
|
Use a verb while naming methods. Add get/ set/ is according to intention of function;e.g., use deletePage() instead of pageDeletion()
|
|
2
|
Use pronounceable, intention revealing names. The reader should be able to pronounce it easily and understand the purpose of the method; e.g., getUserName() reveals intentions of method instead of getNameString()
|
|
3
|
One word for one intention. Don’t use the same word for two purposes; e.g., use insert if you want to add only one item in the collection. Use add if you want to add multiple items.
|
|
4
|
No Similar words. Use the same word instead of using similar wordsl e.g., getUserName(), fetchAddress() makes code difficult to maintain. Instead, getUserName(), getAddress() could be appropriate choice of names.
|
|
5
|
Use camel Case naming convention
e.g. getUserName()
|
|
6
|
While naming overloaded constructor, use argument description in the name
e.g. Complex point = Complex.FromRealNumber(35.0) is easy to use than Complex point = new Complex()
|
Below are certain norms which should be considered while naming a class,
|
No.
|
Norms
|
|
1
|
Use Pascal case naming convention; e.g., Animal
|
|
2
|
Use nouns while naming class; e.g., use AddressParser instead of ParseAddress
|