Code Quality Guidelines

 

This article puts forward some code quality standards, which are incorporated into the habit of writing code everyday, and try to ensure that the Code with few bugs is written under the state of natural consciousness, reduce the chance of writing code containing a large number of bugs. This criterion is used to constrain my personal programming behavior and for your reference. Read more and learn from the excellent source code. Do not write more, but consciously restrain yourself from the inertia of the handwritten code.

Recommended books: code quality, clean code, writing solid Sode, and code Daquan

Preface:

Writing code not only achieves the specified requirements, but also thinks about the associated things to implement the requirements, such as the associated external subsystems and associated requirements.

Out of the current perspective, try to look at the original code from a more macro perspective; Use design thinking to look at and complete programming.

Writing code is not simply typing on the keyboard, but involves a lot of micro-decisions. These micro-decisions will gradually hone a person's thinking and decision-making capabilities.

Accurately understand the API and try to understand every line of code you have written. At least the semantics of the Code must be correct.

1. Write simple and natural code. Follow the usual and common usage as much as possible, as well as the way in which programming languages are used. Odd and clever skills can be posted on the Forum for public observation and appreciation, but should not be placed in the production environment.

2. The logic is clear, concise, and compact. Writing code is just like talking. I want to explain it clearly. The exit should be concise, organized, and neat.

3. plan your ideas before writing the code and make some design-oriented thinking. Sketch out constraints, resources, algorithms, and processes first.

5. Code style consistency. It includes indentation, blank lines, line breaks, spaces on both sides of operators, and names. You can build your own style based on the K & R tcpl style.

6. All inputs should be considered, and valid input ranges should be limited to deny illegal input. Mature library, framework, and data exchange formats (such as XML and JSON) should be used as much as possible, instead of manual parsing.

7. Ensure that the output content is correct and complete, and the format is clear. If the output depends on some variables, ensure that the output can be synchronized when the variables are modified.

8. Use mature algorithms. If necessary, verify the correctness of the calculation method.

9. Capture all exceptions. The error is hidden at the underlying layer to ensure the correctness of the high-level view. Reasonable prompt information and error source information are provided.

10. The comments are concise and concise, indicating the implied meaning that is not easy to guess; specify the reference source when necessary; and indicate the author's information and contact information for communication.

11. jump out of the current perspective and try to examine the original code from a more macro perspective; Use refactoring to eliminate repeated code as much as possible.

12. The Code involving concurrency should be as careful as possible, and the mechanism and risk of the matter should be understood clearly before you start.

13. Isolate the error-prone part and isolate the complicated, obscure, and error-prone manual parsing code from a small corner of the system.

14. Separate variable and immutable parts.

15. Establish unit tests and regression tests.

16. Understand and follow existing specifications. There are only a few violations for good reasons and communication with relevant persons.

The following are some details and precautions:

16. For Code involving a range (array, set, etc.), pay special attention to null values and boundary conditions.

17. Be careful when determining multiple and non-composite conditions. Use the and or operator correctly. In addition, do not misinterpret the operator, for example, write & &. =.

18. Pay attention to synchronous modification when associating variables or methods. For example, the equals and hashcode methods of Java; the edge length and area fields of the circle class.

19. Ensure that the number, type, and order of parameters are correct. accurately understand the API and try to pass in valid and meaningful values.

20. Delayed initialization. a meaningful initial value can be used as the default value.

21. Prevent computing overflow, buffer overflow, SQL injection, and other common security problems.

22. Avoid creating a large number of immutable objects and reuse them as much as possible. Reclaim them as soon as they are used up to prevent memory insufficiency and leakage.

23. It is best not to copy/paste the code, though it is very convenient; if possible, extract the common as a public subroutine.

24. Do not use global variables or share variables.

25. When you are not sure about the priority of multiple compound operations, enclose the operations in parentheses.

26. Perform a non-null check first when operating on Object references or pointers. If it is null, You can provide prompt information, return the default value, or do nothing.

[To be continued]

Bug causes
 

To improve the code quality, we must first discuss why various bugs are generated in the code?

1. some of them are caused by carelessness or negligence, such as making & into &, = into =; for example, boundary errors, compound logic judgment errors, etc; these situations can be avoided.

2. Most of them are caused by inadequate consideration. For example, input problems. When calculating the sum of two numbers, consider not only the computing overflow problem, but also the illegal input. The former can be avoided by understanding, making mistakes, or using experience, while the latter must be limited so that it is within the control of our IQ, for example, use a regular expression to filter out invalid input. Consider error situations and troubleshooting.

3. Some bugs may change over time. Some solutions seem to be good in the past, but they may become clumsy or even useless in current or future scenarios. For example, people's views and attitudes on events also affect program design. There are no programs that can traverse the past and present. Keep pace with the times.

4. Finally, there is another kind of bug that was unexpected, such as hardware faults that caused the flying insects to be stuck in the machine. This situation rarely happens, but it is possible that we must guard against it. In our daily life, how many people have taken the initiative to handle the wrong situation? How many others have performed Exception Handling outside the try block? It is no wonder that people can only seek their own blessings in the face of sudden changes or disasters.