What do you think makes people most impatient when they take over legacy code? Extremely complex UML? I don't think so. My answer is, if with more than two elses, or switch with more than two cases. But is it normal to use a lot of if else and switch cases in your code? wrong! Most if else and switch cases with more than two branches should not appear in hard-coded form.
Where do complex branches come from?
First of all, the first question we want to discuss is why there are often so many complex branches in legacy code. These complex branches often do not exist in the first version of the code. Assuming that the designer still has some experience, he should foresee areas that may need to be expanded in the future and reserve abstract interfaces.
However, after the code goes through several iterations, especially after several adjustments to the requirements details, complex branches will appear. Detailed adjustments to requirements are often not reflected in UML, but directly reflected in code. For example, messages were originally divided into two categories: chat messages and system messages. During design, these were naturally designed as two subcategories of the message category. But then one day the requirements are adjusted in detail. Some of the system messages are important and their titles should be displayed in red. At this time, programmers often make the following modifications:
Add an important attribute to the system message class
Add a branch about the important attribute in the corresponding render method to control the title color. Why would the programmer make such a change? Maybe it's because he didn't realize it should be abstract. Because the requirement says "some of the system messages are important", for programmers who have received more training in imperative programming languages, the first thing they may think of is the flag bit - a flag bit can distinguish between important and non-important ones. important. He did not expect that this requirement could be interpreted in another way, "System messages are divided into two categories: important and unimportant." Interpreting it this way, he knew that the system messages should be abstracted.
It's possible, of course, that the programmer knows abstraction is possible, but for some reason chooses not to do so. A very common situation is that someone forces programmers to sacrifice code quality in exchange for project progress speed-adding a property and a branch is much simpler than abstract refactoring. If you want to do 10 of this form Modify, is it faster to make 10 branches or 10 abstractions? The difference is obvious.
Of course, if there are too many if elses, some smart people will stand up and say, "Why don't we change it to a switch case?" In some cases, this can actually improve code readability, assuming each branch is mutually exclusive. But when the number of switch cases increases, the code will also become unreadable.
What are the disadvantages of complex branches?
What are the disadvantages of complex branches? Let me take a section from the old code of Baidu Hi web version as an example.
switch (json.result) {
case "ok":
switch (json.command) {
case "message":
case "systemmessage":
if (json.content.from == ""
&& json.content.content == "kicked") {
/* disconnect */
} else if (json.command == "systemmessage"
|| json.content.type == "sysmsg") {
/* render system message */
} else {
/* render chat message */
}
break;
}
break;
Source: Baidu pan-user experience