Naming conventions are intended to enhance identification and readability. There are no mandatory rules, but once a convention is chosen, it is recommended to maintain a consistent format during coding. Chemistry, astronomy, and biology also have their established naming methods; most programming languages also offer recommendations to unify style.
In programming design, when names for variables, functions, and classes consist of combinations of two or more words, existing naming conventions can be used to improve identification and readability. Currently, naming conventions can be categorized into three main types: Underscore (snake_case), Camel-case, and Hungarian notation. This article compiles these methods and discusses their pros and cons based on personal experience.
1. Underscore (snake_case):
Words are separated by underscores. This is the most common convention in GNU/Linux environments, for example: string_name.
Pros:
Using underscores instead of spaces makes reading more intuitive and easy to understand.
Cons:
Compared to Camel-case, which uses capitalization of the first letter to replace spaces, underscores are less frequently used in daily typing, requiring some adaptation.
2. Camel-case:
Words are separated by capitalization. It can be further divided into Lower Camel-case (lower camel case) or Upper
Camel-case (upper camel case), the latter of which is also known as Pascal-case.
Lower Camel-case(Lower Camel-case):
The first letter is lowercase. This variation is commonly used for variable names, for example: stringName.
Upper Camel-case (Upper Camel-case):
The first letter is uppercase. This variation is commonly used for functions, classes, properties, and namespaces, for example: StringName.
Pros:
- Capitalization at the beginning of the name can be used to distinguish variables from functions, classes, and other types.
- Using capitalization instead of underscores between words can reduce the length of names, minimizing the chance of code being obscured when it exceeds the window width.
Cons:
- Compared to Underscore, which uses underscores instead of spaces, reading is less intuitive and easy to understand.
3. Hungarian notation
Based on Camel-case, predefined abbreviations are added as prefixes to names. For example, conventions might be as follows:
b boolean c character str C++ String si short integer i integer li long integer f floating point d double-precision floating point ld long double-precision floating point sz Old-Style Null Terminated String if Input File Stream is Input Stream of Output File Stream os Output Stream S declaring a struct C declaring a class Source: http://web.mst.edu/~cpp/common/hungarian.html
Depending on the purpose of the abbreviation, it can be divided into Systems Hungarian and Apps Hungarian.
Systems Hungarian：
The name prefix represents the actual data type, for example: strName.
Apps Hungarian：
The name prefix represents the purpose or other hints, for example: usName, where ‘us’ stands for ‘unsafe’, indicating that filtering must be performed afterwards to prevent Code injection or XSS.
Pros:
- Types can be identified from the name without requiring IDE support.
- Well-defined coding rules make searching more consistent and easier to find.
- Well-defined coding rules allow for faster naming and typing.
Cons:
- Requires learning additional coding rules.
- Modern IDEs can easily distinguish types, making this method somewhat redundant for data types.
- When a variable’s type is modified, the name must also be corrected and maintained.
- Using abbreviations for naming is less friendly to beginners; for example, szName is less clear than stringZeroName.
- It is also more prone to ambiguity; for example, szName is more likely to be misread as having a different meaning, and it is difficult to search by guessing keywords.
