Here’s a summary of some bad code specifications to warn yourself against such mistakes

annotation

1. Inappropriate comments

Comments should only be used to describe technical information about the code and design. Information such as modification history should not appear in comments

Deprecated comments

Comments that are obsolete, irrelevant, or wrong are obsolete comments. Do not write such comments, and if found, update or delete them as soon as possible, otherwise it will become further and further removed from the code it started describing

3. Redundant comments

Don’t comment if the code speaks for itself, for example:

i++; / / I gainCopy the code

Comments should say something that the code itself doesn’t say.

4. Commented out code

Typically, commented out code is probably no longer relevant to the existing system, calling variables or functions that have been renamed and rendered useless

Functions and classes

1. Too many parameters

A function should have zero arguments. If it has more than three arguments, encapsulation may be considered

2. Identify parameters

If a function argument has a Boolean value, it is just confusing. It can be split into two functions, and enumerations are the same

3. Die function

Functions that are not used should be removed as soon as possible

4. Dead code

Dead code is code that will not be executed. It may occur in an if statement that will not fire, or in a try catch that will not throw an exception. If you find such code, please delete it this morning.

5. Vertical distance

Variables should be declared above the first use. The function should be placed just below the first call

6. Inconsistency

If the response object is named Response in one place, it should be named response elsewhere. If you name a method getCommonModule, methods that handle similar things should have similar names, such as getUserModule. This will make the code throw easy to read and modify.

7. Wrong placement

For a function or a position where it is always on, place it where the reader naturally expects it to be

8. Inappropriate static methods

If a method is named static, it requires all the variables and parameters, not the properties of the object, and it does not use polymorphisms.

Of course some methods are called static, such as math.max (a,b), but new Math().max(a,b) would be silly

Incorrect function names

If you see a function name and still wonder about its intent, or even look at the source code, change the name.

10. Wrong level of abstraction

When writing methods, it is easy to think that functions should be drawn down one layer at a time, and that there should be no layer functions calling higher-level functions, just as base classes should not depend on derived classes.

11. Package conditions

In conditional statements like if, while, etc., the following is written:

if(shouldBeDeleted(timer)){}
Copy the code

Significantly better than:

if(timer->hasExpired() && ! timer->isRecurrent()){}Copy the code

12. Hide the call order

In a class, there is code like this:

public function eat(Person $p){
    buyGreens();
    makeDinner();
    eatDinner($p);
}
Copy the code

This code is easy to understand. First buy food, then cook, then eat. Obviously, when you buy food, you assign a value to the attributes of the class and use it when you cook. But if they call in the wrong order, uninitialized variables will be used. If you change it to the following:

public function eat(Person $p){
    $greens = buyGreens();
    $dinner = makeDinner($greens);
    eatDinner($dinner, $p);
}
Copy the code

This exposes the order in which functions are called. Each function produces what the next one needs, so there is no reason not to call in order.