How to write well-formulated code

The way to clean and standardized code

Knowing the meaning by seeing the name: You can easily know the general purpose based on the name, instead of using pinyin abbreviations, which is confusing.
Meaningful distinction: When the uses are different, remember to distinguish the names to avoid misuse due to similar names.
Avoid using encoding (letters, numbers, suffixes, etc.): the uses and differences cannot be well understood, which increases the cost of understanding.
Class name, object name, use noun or noun phrase
Method names should be verbs or verb phrases: it is easier to understand what the method does
Each concept corresponds to a word, which is consistent and convenient for subsequent searches:

For example, search includes get/find/obtain/search, etc. It is recommended to use unified concepts to reduce understanding and communication costs.

Be short and avoid overly long functions. If they are too long, they can be extracted into small functions: to enhance readability, and small functions can be reused, reducing the cost of modifying the main function.
Single responsibility: a function only focuses on one thing to avoid bloated functions
Input parameters should be as few as possible: too many parameters increase the cost of understanding, and it is easy to pass wrong parameters; if there are too many parameters, consider encapsulating them into an entity
Use exceptions instead of returning error codes: The judgment of error codes will lead to a deeper nested structure. The caller needs to understand the error codes, and it is difficult to judge whether the error code is an exception or a business error.
Extract the try/catch code block into a new function, and try/catch only includes the exception code: reduce the granularity of try/catch and maintain performance
DRY principle to avoid duplication of code: duplicate code can be extracted and reused, reducing the cost of subsequent code changes
Use third-party libraries: Prioritize the use of methods provided by class libraries. Codes that have been verified multiple times have a lower probability of bugs and can be used selectively; avoid pitfalls and reinventing the wheel by writing your own code.

Comments cannot beautify bad code: elegant code is the foundation, don’t try to cover up bad code with too many comments
Use good code names that are self-explanatory: avoid too many redundant comments
Warning places must be commented: add comments in key places to encourage attention when making changes.

vertical format
1. learn from newspapers
2. Code blocks of different concepts are separated by blank lines: improving readability
3. Closely related code should be close to: high cohesion
4. vertical distance
  1. Local variables: as close as possible to where they are used
  2. Entity variables: declared at the top of the class
  3. Related functions: Functions of the same type call each other, and the caller is placed above the callee as much as possible.
  4. Related concepts: related code should be put together
landscape format
1. Avoid single lines that are too long
2. Horizontal alignment
3. Pay attention to the indentation level

Guard statement return: For conditions that do not meet the requirements, use guard statements to quickly fail and return to avoid excessive branch judgments.
Avoid magic values: The meaning of magic values may only be known at the time of writing, and subsequent understanding is extremely costly; it can be extracted into a constant class or enumeration for unified management
When the value of a member variable does not change, it is preferred to define it as a static constant.
Pay attention to checking the null pointer, especially when calling in a chain
Minimize the visibility of class members and methods: the least known principle to avoid incorrect calls
Minimize double counting of variables