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 |
Join the conversation! Your thoughts help the community grow.