Let code refactoring fade-away series (1) -- remove multi-layer nesting

Reconstruction background and causes

Recently, due to the continuous expansion of the project team, the Code style in the project varies, and the project may be full of flowers or even anger. Taking into account the survival and development of the team, after many battles, the project team was finally decided to be divided into several teams based on the business to strengthen team management and improve efficiency, while also cultivating tiered talents. For the sake of "Uniform" code style, each team improves the code capability of members so as to ultimately improve the quality of project code and reduce the maintenance cost in the future, the final decision is "Daily" for code lookup/review in the group, and then code refactoring.

 

Remove multi-layer nesting: The following Code refers to the so-called multi-layer nesting:

1 Public bool multi-layer nesting (string parameter 1, string parameter 2, string parameter 3, string parameter 4) 2 {3 if (! String. isnullorempty (parameter 1) 4 {5 // Process Code 6 7 if (! String. isnullorempty (parameter 2) 8 {9 // The processing code 10 11 if (! String. isnullorempty (parameter 3) 12 {13 // The processing code of parameter 3 is omitted here. 14 15 if (! String. isnullorempty (parameter 4) 16 {17 // The processing code of parameter 4 is omitted here 18 return true; 19} 20} 21} 22} 23 24 return false; 25}

View code

The nesting of the above Code not only increases complexity, but also is not conducive to reading, especially when there are too many logic code processing in the IF condition, the number of If packages nested at the first layer is quite large, which increases the difficulty of reading and is not conducive to future maintenance, especially for others.

Some friends may say that my business is like this. What can I do? I want to tell the customer that this business is too complicated. You can simply wait ........ is there really no way? In fact, there are always ways to deal with this Code. It depends on your willingness to think about it. How should we deal with this code?

In fact, we have different processing methods based on different scenarios.

Scenario 1: Each if condition does not affect each other, or is not dependent on each other, it can be processed as follows:

1 Public bool remove multi-layer Nesting Method 2 (string parameter 1, string parameter 2, string parameter 3, string parameter 4) 2 {3 if (string. isnullorempty (parameter 1) | string. isnullorempty (parameter 2) | string. isnullorempty (parameter 3) | string. isnullorempty (parameter 4) 4 {5 return false; 6} 7 8 // The processing code 9 10 return false; 11} for parameter 1, 2, 3, and 4 is omitted here}

View code

Scenario 2: When conditional statements are sequentially dependent on each other, we can process them as follows:

1 Public bool remove multi-layer Nesting Method 1 (string parameter 1, string parameter 2, string parameter 3, string parameter 4) 2 {3 if (string. isnullorempty (parameter 1) 4 {5 return false; 6} 7 8 // The processing code of parameter 1 is omitted here 9 10 if (string. isnullorempty (parameter 2) 11 {12 Return false; 13 14} 15 16 // The processing code 17 18 if (string. isnullorempty (parameter 3) 19 {20 return false; 21} 22 23 // The processing code 24 25 if (string. isnullorempty (parameter 4) 26 {27 return false; 28} 29 30 // The processing code for parameter 4 is omitted here 31 32 return true; 33 34}

View code

Summary:

When we begin to write this business logic, we may unconsciously write it into the form before restructuring, so that after a while we have to become familiar with the code, understand the code, and then refactor the code, so why don't we choose the appropriate method for business scenarios when writing code?

If we think about this when writing code, do we still need to spend more time doing This refactoring? How can code reconstruction not get farther and farther away?

　　

Let code refactoring fade-away series (1) -- remove multi-layer nesting