Have you smelled code corruption?

The bad taste of code refers to the warning signal of potential problems in the code. Not all bad taste indicators are indeed a problem, but it is necessary to check and modify most bad tastes. If you see the same program structure in more than one location, the program will become better if you are sure to combine them into one.

The bad taste of code refers to the warning signal of potential problems in the code. Not all bad taste indicators are indeed a problem, but it is necessary to check and modify most bad tastes.

1 .? Repeated code

If you see the same program structure in more than one location, the program will become better if you are sure to combine them into one.

• The two functions in the same class contain repeated code segments.
• The member functions of the two sibling classes contain repeated code segments.
• Duplicate code segments appear in two irrelevant classes

Note: duplicate code is a hotbed of most potential bugs!

2 .? Long functions

Objects with short functions will be better and longer-lived.

• The longer the program, the harder it is to understand
• Function reading is too long and inconvenient.
• Value of small functions: interpretation, sharing, and selection

Principle: whenever we feel that we need to annotate something, we write the things to be explained into an independent function. Remember, give a good name!

3 .? Category

If you want to use a single class to do too many things, too many member variables will usually appear in it.

• Extract the variables related to the same task to a new class.
• For classes that do too many things, you can consider entrusting the responsibility to other classes.

Note: If a class has too much code, it is also a perfect breeding place for repeated, chaotic, and dead code.

4 .? List of too long parameters

Too long parameter lists are hard to understand. too many parameters may cause inconsistency and inaccessibility, and you have to modify them when you need more data.

Principle: no more than 3 parameters are allowed!

5 .? Divergent changes

We hope the software can be modified more easily. Once modification is required, we want to jump to a certain point of the system and only make modifications here. If you cannot do this, you will find "bad taste: Divergent changes" or "bad taste: elastic modification ".

Divergent changes: a class is affected by multiple changes

• The database adds a new field and modifies three functions at the same time: Load, Insert, and Update.
• Add a new role binary and modify it everywhere.
• ...

Principle: all modifications to an external change should only occur in a single class.

6 .? Elastic modification

If you encounter a change, you must make many small changes in many different classes to respond to it. If the code to be modified is spread around, it is not only difficult to find them, but also easy to forget an important modification.

Elastic bullet modification: a change causes the corresponding modification of multiple classes.

7 .? Attachment plot

If a function is more interested in a class than in its own class, an attachment to the class will be generated, resulting in tight coupling.

Principle: determine which class has the data most used by this function, and then put this function and that data together.
Principle: put things that are always changing together.

8 .? Data Dashboard

Some data items like waiting in groups. Then bind them to a new class. In this way, you can:

• Shorten the parameter list
• Simplify function calls

9 .? Basic type paranoia

The code contains many basic data types.

Principle: If you see some basic data types, try to define a new data type that meets the object type currently represented by it.

10 .? Switch thrilling appearance

One of the most obvious features of object-oriented programs is that less switch statements are used. Essentially, the problem with switch statements lies in repetition.

Principle: If you see a switch, you should consider replacing it with polymorphism.

11 .? Redundancy

Every class you create has to be understood and maintained by someone, but when there is no need for a class, let this class be solemn!

Principle: If the income of a class is not worth its value, it should disappear.

12. talk about its future

Too much consideration for unpredictable changes in the future makes the system more difficult to understand and maintain. If the code to deal with changes will be used, it is worth doing so; if not, it is not worth it.

Principle: the code should meet the current needs and leave room for expansion. For future changes, do not consider too much or not at all.

13 .? Confusing temporary member variables

Sometimes you will see an object where a member variable is set only for a specific situation. Such code is easy to understand, because you usually think that an object needs all its variables at all times.

If the variable is not used, you can guess that the purpose you set will drive you crazy.

14 .? Useless intermediary

Excessive use of delegation. You may see that half of the functions of a class interface are delegated to other classes, so that they are over-used. Therefore, remove useless middlemen.

15 .? Relationship

Sometimes you will see two classes that are too close and spend too much time exploring the private components of each other.

Principle: classes that are too popular must be broken up.

16 .? Similar class

If two functions do the same thing, they have different signatures.

Principle: delete and retain one.

17 .? Imperfect Library

The database design is sometimes not good enough and is not easy to use. it may have a small defect.

Tools:

• Introduce Foreign Method
• Introduce Local Extension

18 .? Too many comments

Too many comments of code segments are often caused by poor code that emits a foul smell.

Principle: when you feel that you need to write comments, try refactoring and try to make all comments redundant.

Address of this article: http://www.nowamagic.net/librarys/veda/detail/1761,welcome.