1, the introduction

This standard is to measure the flaws of the code itself, but also to measure the value of a developer himself. Huawei, as a global IT company, has more than 100,000 employees. IT is not easy to manage both personnel and code. IT is a terrible thing to think about without normative constraints. The following content does not involve the basic syntax (see Refer), but focuses on some programming habits and how to improve the robustness and maintainability of programs. (PS: the following content without official research, such as readers experiencing discomfort, please choose to close this page now -_ – | | |)

2. Introduction of military regulations

Catch-1: Avoid using devil numbers in your programs. use meaningful constants.

Catch two: [clear method function, a method only complete a function.

Catch-3: [Method parameters can not exceed 5]

Catch 4: Method calls should not return NULL, but instead throw exceptions or return SPECIAL CASE objects (SPECIAL CASE patterns); for methods that return values of collection or array types, empty collections or zero-length arrays should be used instead.

Catch-5: When performing database or IO operations, you must ensure that the resource is released after use, and you must ensure that the release operation is performed in finally.

Catch 6: don’t catch (Exception ex) directly, you should subdivide the Exception.

Catch seven: If “else if” (there may be multiple else if…), an else branch must be included at the end to avoid branch omissions; each switch-case statement must have default to avoid branch omissions.

Catch 8: Overriding the equals() method of an object must also override the hashCode() method.

Catch 9: Prohibit the creation of new threads in the loop, try to use the thread pool.

Avoid floats and doubles for exact calculations (e.g., currency calculations); floating-point calculations are imprecise; you must use BigDecimal or convert floating-point operations to integer operations.

3. Instructions on military regulations

Catch-1: Avoid using devil numbers in your programs. use meaningful constants. Note: The devil number should be based on easy to read and global substitution principles. 0 and 1 must be defined as constants when enumerating values of physical quantities in a specialized field. “Devil constants” such as NUMBER_ZERO are prohibited.

Catch two: [clear method function, a method only complete a function. Note: Too many methods will increase the complexity and dependency of methods, which is not conducive to program reading and future continuous maintenance. Both method and class design should conform to the principle of single responsibility.

Catch three: [Method parameters should not exceed 5] description: Too many parameters affect the code to read and use, to reduce the parameters, the first thing to consider the rationality of these parameters, single function, maintain method optimization method to design, if the parameter does not decrease, multiple parameters can be encapsulated into a class (object), at the same time, considering the new class (object) with the corresponding increase in behavior, in order to more accord with OOP.

Catch 4: Method calls should not return NULL, but instead throw exceptions or return SPECIAL CASE objects (SPECIAL CASE patterns); for methods that return values of collection or array types, empty collections or zero-length arrays should be used instead. Note: Returning null adds unnecessary NullPointerException judgments, and omitting judgments can result in serious NullPointerException errors.

Catch-5: When performing database or IO operations, you must ensure that the resource is released after use, and you must ensure that the release operation is performed in finally. Description: Database operations, IO operations, etc., must be closed in finally of try-catch-finally. If more than one IO object needs to be closed, The close() method of each object must be try-caught to prevent an I/O object from being closed.

Catch 6: don’t catch(Exception ex) directly, you should subdivide the Exception. Description: The result of catch (Exception ex) will catch RuntimeException. RuntimeException is a run-time Exception thrown by the program itself without consideration. RuntimeException is a BUG thrown by the program, such as invalid parameters, array out of bounds, division by zero, etc. The program must ensure that it cannot throw runtimeExceptions, and that it is not allowed to show that runtimeExceptions are caught to make it easier to detect program problems during testing.

Catch-7: If “elseif” (there may be multiple elseif…) this type of condition judgment, the last must include an else branch, avoid branch omission error; each switch-case statement must have default, avoid branch omission error.

Catch 8: Overriding the equals() method of an object must also override the hashCode() method. Note: The equals and hashCode methods are the basis of the efficient work of objects in the hash container. The correct overwriting of these two methods can ensure the correctness of the lookup of objects in the hash container, and a good hashCode method can greatly improve the efficiency of the hash container.

Catch 9: Prohibit the creation of new threads in the loop, try to use the thread pool.

Avoid floats and doubles for exact calculations (e.g., currency calculations); floating-point calculations are imprecise; you must use BigDecimal or convert floating-point operations to integer operations. Explanation: Floating point arithmetic provides good approximations over a wide range of values, but it does not yield precise results. Binary floating point is very unsuitable for precision calculations because it is impossible to accurately represent 0.1 — or any other negative power of 10 — as a binary decimal of finite length.

Please refer to the specific cases: floating-point addition problems: the binary representation of floating point my.oschina.net/leejun2005/…

4. Some suggestions and experiences about development efficiency and collaboration

Today, I saw an email written by a student to a team member, and found it quite common. Please share it with me:

1. Small submission:

Divide large tasks into multiple independent small tasks, and after each small task is completed to ensure no bugs, it can be submitted and merged into the main branch or even published; Frequent submissions help me keep track of the project, reduce risks, collaborate with others, and Review code. You can submit merges multiple times per day. Each small task is a granularity that can be completed in 1-2 hours, with the maximum completed in one day. When doing multiple tasks in parallel, prioritize the tasks that can be done in the shortest time.

2. Naming conventions:

Try to avoid nonsense characters as variables such as a, b, and t. Can gradually improve, can refer to: google-styleguide.googlecode.com/svn/trunk/j…

3, avoid excessive design: can be realized in a simple way, do not introduce complex classes, objects, avoid unnecessary new objects, avoid the introduction of unnecessary generics, threads. Early development redundancy is greater than abstraction and dependency. Avoid reimplementing generic components and functions yourself. When investigating multiple implementations, choose simple implementations. Write as little code as possible.

4. Web engineering tries to avoid saving “state” inside the application, so that it can adapt to frequent release and restart without impact.

5, good at using log debugging, log at key points in the program. Use breakpoint mode as little as possible, log mode can batch debug a batch of functions, relatively high efficiency.

6. Avoid large functions that cannot be displayed on one screen.

7. Add necessary, concise comments:

Single-line comments for continue and break in loops as much as possible; Avoid non-function ending returns and comment them if necessary. Class automatically generates toString() methods for easy debugging and logging.

8. Don’t limit yourself to a certain function. Everyone is the Owner of the whole project.

9. Communicate with others in time to avoid wasting time.

10. Review your own small design from the final product goal, and familiarize yourself with the upstream and downstream code of your responsibility. Keep an eye on the final product (Web interface and logs) to find bugs and areas that can be improved.

Source: blog.csdn.net/chenleixing/article/details/44173985