Ten Commandments of Programming

Original article:Http://cocre.com /? P = 1007(Cool Shell)

1.-Dry: Don't repeat yourself.

Dry is the simplest rule and the easiest to understand. But it may also be the most difficult to be applied (because to do so, we need to make considerable efforts in generic design, which is not an easy task ). It means that when we discover similar code in two or more places, we need to abstract their commonalities to form a unique new method, and change the existing code so that they can call this new method with some appropriate parameters.

The dry rule may be the most common rule in programming. So far, no programmer has any objection to this rule. However, we can find that some programs forget this rule when writing unit tests: Let's look at it. When you change Several Interfaces of a class, if you do not use dry, the unit test programs that call the interface of a series of instance classes must be manually modified. For example, if many test cases of your unit test do not use a common method to construct classes, but each test case constructs its own class instance, then, how many test cases do you need to modify when the class constructor is changed. This is the consequence of not using the dry law.

 

2.-Short method.

At least, we have three good reasons to ask programmers to write down short methods.

1. The code will become easier to read.
2. Code will become easier to reuse (short methods can reduce the degree of coupling between codes)
3. The code will become easier to test.

3.-Good naming rules

Using a good unified naming convention can make your program easier to read and maintain. When a class, a function, when the name of a variable reaches the realm of "looking at the meaning of life", we can have less documents and less communication. The article "Naming design in programming" can give you some tips.

4.-assign correct responsibilities to each class

For a class and a responsibility, refer to the class'sSOlid rule. However, what we emphasize here is not a single responsibility, but a correct responsibility. If you have a class named customer, we should not have the sales method for this class. We can only make this class have the most direct relationship with customer.

5.-organize the code

The code is organized in two layers.

• Physical Layer Organization: No matter what directory, package, or namespace structure you use, you need to organize your class in a standard way, this facilitates searching. This is a physical code organization.
• Logical layer organizationThe so-called logic layer mainly refers to the association and organization of two classes or methods with different functions through a certain specification. The main concern here is the interface between program modules. This is the architecture of common program modules.

6.-create a large number of unit tests

Unit testing is the closest to bugs and the lowest bug modification cost. It also determines the success or failure of the entire software quality. Therefore, if possible, you should write more and better unit test cases, so that when your code changes in the future, you can easily know whether your code changes affect other units.

7.-rebuild your code frequently

Software development is a process of continuous discovery, so that your code can keep up with the latest changes in actual needs. Therefore, we need to rebuild our code to keep up with such changes. Of course, refactoring is risky. Not all refactoring is successful, nor can we refactor code at any time. The following are the first conditions for refactoring code to avoid introducing more bugs or getting worse code.

1. There are a large number of unit tests for testing. As mentioned above, refactoring requires a large number of unit tests for protection and testing.
2. Every reconstruction should not be big. We should replace the large reconstruction with a small one. Too many times, when we plan to refactor 2000 lines of code at the beginning, and three hours later, we will discard the plan and restore the code to the original version. Therefore, we recommend that you rebuild from scratch.

8.-program comments are evil.

This article must be controversial. Most Programmers think that program comments are very good. Yes, that's right. Program comments are very good in theory. However, in actual programs, the comments written by programmers are very bad (the expression ability of programmers is very problematic), which leads to program comments becoming the embodiment of all evil, this also causes us to read code without reading comments most of the time. So here, we do not encourage you not to write comments, but -- if your comments are not well written, you might as well spend more important time refactoring your code to make your code easier to read and clearer, which is better than comments.

9.-Focus on interfaces rather than implementation

This is the most classic rule. What the interface focuses on is that "what" is abstraction, and what the implementation focuses on is-"how" is details. The interface is equivalent to a contract Contract, and the actual details are equivalent to an operation and implementation of this contract. The operation can be flexible, and the contract needs to be relatively stable and unchanged. If an interface is not well designed and requires frequent changes, we can think about the consequences of this generation. This is definitely a very high cost. Therefore, interfaces are the top priority in software development and configuration, rather than implementation. However, our programmers always focus on implementation details, so their local code is very well written, but the overall design of the software is relatively poor. We need to pay more attention to this.

10.-Code review mechanism

Everyone will make an error. The probability of a person making an error is very high. The probability of two people making an error is smaller, and the probability of a person making an error is smaller and smaller. Because, when there are too many people, we can look at one thing from different perspectives. Although this may lead to an inefficient debate, the maintenance costs of problems after software product release are compared, this cost is quite worthwhile. Therefore, we need different people to reivew Code. The Code review mechanism is not only the most effective mechanism for Problem Discovery, but also a mechanism for knowledge sharing. Of course, there are several basic principles for code review:

• The examiner's ability must be greater than or equal to the Code author's ability. Otherwise, code review becomes a new kind of training.
• Furthermore, in order for the examiner to be truly responsible, rather than being perfunctory in the review, we need to make the examiner primarily responsible for the reviewed code, rather than the author of the Code.
• In addition, a good code review should not be performed when the code is completed, but be constantly iterated during the code writing process. Good practice, no matter whether the code is complete or not, it takes several days to review the code.

(I described this article in my own language and joined my personal experience. Therefore, please pay attention to the author and source during reprinting, and do not use it for commercial purposes.)

 

Article: Source