Is your code complete? (II) -- maintainability and standardization

Ii. maintainability and standardization

ForCodeThese two attributes are closely linked. What kind of code is best maintained? Of course it is a standard code.The standard is much better than that without a standard.

When I was working on a Japanese project, the Japanese people had extremely strict requirements on the "Regulations" (they call it the Development Statute. On the one hand, strict regulations will be formulated for everyone to comply with, including not only the naming and code format rules, but also the distance between each control and the code comment format, the proportion of comments in the code, how to write each code structure (loop, selection, etc.), and when to add blank lines, generally, their code specifications contain at least 10 pages. On the other hand, they have also developed a relatively complete process to ensure standard execution. After code development is completed, the first step is to review the code and then perform a standalone test. These two processes are not in some domestic projects, they are just taking a pass, and even standards have been set up in Japanese projects. Each thousand lines of code must review the number of problems, the number of bugs that must be tested is limited. If the standard is not met, this process cannot be passed unless there are sufficient reasons.

After so many strict procedures, the goal of the Japanese project is"All the code looks like written by a person.". Although this is somewhat idealistic, after all, the ideas for everyone to handle the problem will be somewhat different, but as far as the Code is concerned, it does seem clean, just as it is written by the same person. Naturally, it does not seem to be too serious during maintenance.

On the contrary, in some domestic projects, the emphasis on code specifications is obviously insufficient. Many codes do not solve the most basic indentation and naming problems, let alone the length of each method, class and interface design. Sometimes, when I have to modify such code, I will first sort out the specification and then modify it. However, like the broken window theory, sometimes when you are in a bad mood, you will not make any changes at all, or even add more non-conforming things. (That's very rare, haha. And I won't sign it. You can steal it !)

From this point of view, whether the newly written code complies with the code specifications will greatly affect the future maintenance and modification work.

What is maintainability reflected in? I think it is aboutProgramCan you quickly locate the problem during the modification and easily understand the work to be done by the Code while reading the code, in this way, the code can be modified more quickly and effectively.

This will inevitably involveNoteThere have been a lot of discussions about this thing. My point is that if you can use a better name and clear code to illustrate the problem, you can leave it empty. On the contrary, if you only look at what the code cannot understand, especially the business knowledge, or some special requirements in the business process, it is very necessary to write comments, otherwise, the maintenance personnel will not understand why. The comments rate in the Code specified in the daily project is too much.

For itself, it is not very difficult to write standardized and maintainable code, mainly in attitude. I remember when I first trained new people in the company, I once said, "what kind of code should we write? I think there is a principle:When others modify and maintain your code in the future, He ***, who wrote the ghost code, and gave me the impulse to beat people ." Haha, it's just a joke, but I can still explain some problems.