I recently participated in several code review sessions. During the review process, I found that some problems appeared almost every time. I picked a few typical questions to explain. These questions are all primary problems and the solutions are easy. As long as you master the method and consciously avoid it, you can quickly improve the code quality in a short time. The so-called small investment, quick results.

The variable name is not clear, the word is meaningless

The most important consideration when naming a variable is that the name describes the transaction represented by the variable completely and accurately . Easy to read and not confused with other transactions.


if(staff_id == 0)
    printf("System archive, not employee archive");

In the above code, staff_id is the meaning of the employee number, and the staff_id is 0 to indicate that it is a system archive. The word polysemy should have been separated from the system, but mixed with a variable. If the caller has a bug that forgets to assign the initialized variable, it will go to the unexpected logic.

The solution is that the variable name must first conform to the actual meaning of the variable, without ambiguity; for a variable name, no special value is used to represent special logic .

Some code will give other meanings to the values ​​that the variables can’t take. It feels like saving things, and the actual troubles are endless. For example, if the username cannot be empty, a null value indicates that the user data has been deleted. And the code that determines whether the data is deleted is also confusing.

In short, variable naming should ensure that there are no “hidden rules” to prevent digging holes for yourself.

Use magic number

The naming is unclear and more serious, there is no naming, use the magic number directly. If you don’t even have a comment, you can only guess.

There are two bad places to use magic numbers:

1. It is not convenient to modify.

Using a constant to replace a magic number is a way to “parameterize” a program. You need to modify the changes in one place, without having to modify them everywhere. 
For example, the default binding port in the code is 80. If you do not use a constant instead, the software default port will be changed to 443. Searching the entire code for 80 is both time consuming and error-prone.

2, the code is not convenient to read.

With only one number, it is difficult to understand the specific meaning.

for(int i = 0; i < 13; ++i)

The above code, just look at 13, who can guess what it means, why use the value of 13? Maybe only the person who wrote the code and God knows that if the person who wrote the code forgot for a long time, only God knows.

Some students will also ask, some numbers only use one place, but also a constant name will it be too much trouble?

The answer is: no trouble. It is okay to give a good name to the magic number. This is the right thing. Don’t do it because of trouble. Sometimes you have to check the dictionary in order to get an accurate name.

There is a common way to judge:

First, if there are no more than three places to refer to the magic number, the direct use of the number is not significant. If more than three, it means the same numerical meaning, or use a meaningful variable name instead.

Second, if the magic number itself is a purely numerical definition, such as a few meters, a few kilograms, as a parameter. The definition of the function clearly indicates the meaning of the shape parameter. When you look at the places and function definitions you use, you know how many units mean the number, you can use the magic number. But if the type is represented by a number, for example

const int ieBrowser=1;
const int chromeBrowser=2;

Indicates the type of browser. If you just see 1 or 2, you don’t understand what it means. Don’t use magic numbers even if the browser has been said to be a browser type.

The magic number solution is very simple: use enumerations, constants, etc. instead of magic numbers .

If else or switch, logic statement is too long

For example, the pseudo code code below has a lot of conditional branches. A long if else statement or a switch statement can be used to express complete logic. It is necessary to think about whether it can be optimized by using “table-driven” method.

const int CN=1;
const int US=2;
const int UK=3;

string language;
else if(country==US)
else if(country==UK)

There are a few bad conditions when the conditional branch is too long:

1, the code is too long, not easy to read.

If you exceed the length that a screen can represent, you have to turn the page to see the code, which will greatly reduce the efficiency of looking at the code. Because the information density of the code is too low.

2, not easy to expand, modify the code.

Just like the above example, if a new conditional judgment is added, then a new if else statement is added. Since the logic is modified, it is necessary to retest and prevent mistakes.

You can replace the too long logical branch with a “table driven” approach .

Put the data to be used in each condition into a “table”. The conditional branch is used to index the data in the table. 
The above code can be modified to

const int CN=1;
const int US=2;
const int UK=3;

string languageTable[]={"","中文","English","English"};
//first judge country is in CN、US、UK , or continue
language = languageTable[country];

After modification, the code becomes very short and you can see the logic represented by the code at a glance. And only the data is updated in the future, the logic part does not need to be modified.

After using Table Drive, the logic and data are separated. Make the new data modification simple and clear at a glance.

to sum up

The above is just a brief description of several common code writing errors. With a little attention, you can quickly improve the quality of your code in a short period of time. Specific methods can refer to some code specifications, or refactored books, such as “table-driven” will be more detailed.

The most essential thing is to have enough understanding from the consciousness. The code is written for people to read, and there must be empathy when writing the code. I think that people who read the code should try to read it as much as possible. Empathy, if you are a reviewer, or someone who takes over the code later, would you like this code?

After all , the number of times the code is read far exceeds the number of times written. Make sure the code is easy to read, not just easy to write