After learning the syntax and a bunch of APIs, beginners will try to write their own fully functional programs. It’s easy to get into the habit of writing a method with hundreds or even hundreds of lines. In general, this is a lack of abstraction, design, and encapsulation in thinking. With programming experience, there is always a day to overcome.
But if you want to get over it early and think like a professional programmer, read a lot about design and code readability. There are many classic books in the industry, such as Design Patterns, Refactoring, Clean Code, Implementation Patterns, and so on. I highly recommend these four books because I personally learned a lot from them and feel they are all must-reads.
Be careful when your methods don’t fit on one screen.
The disadvantages of the long method are numerous, mainly reflected in the following aspects:
A long method can contain too many variables.
Long methods have more logic and more variables. Too many variables often accompany the following problem:
1. Naming difficulties. When you define a List with four elements of type UnfinishedCustomOrder, and a List with four elements of type FinishedCustomOrder, these variable names are very long, and if you don’t have good eyes, they can be used incorrectly and become bugly.
2, heavy (chong) with variables. Beginners’ naming of variables is arbitrary, and the use of variables is arbitrary. For example, define a Boolean Flag variable, which you used once in this piece of logic, and then again in that piece of logic.
3. Repeated variables. When a method is long enough, it is often written to the end and forgotten. This leads to, for example, going back to the database and looking up something that has already been looked up once. This is especially true in code that has been modified many times, each time by a different person.
4. Change the content of the variable but forget it. Like this:
public void processAllOrders() { List allOrders = ... ; // Enquire all orders... // exclude completed orders. Note that this statement may even be delegated to // another method, not seen in this method. allOrders.removeAll(finishedOrders); . . // Two hundred lines of code later... . . // At this point, another programmer takes over to implement the requirement change. AllOrders.foreach (order-> {...) {// AllOrders.foreach (order-> {... }); . }This is a serious violation of coding principles. Some people say, is it that the programmer who takes over is not reading the code carefully? Note that reading code itself is mentally draining. Reading code is not reading a novel. You have to understand the behavior of the code closely. If the code is poorly readable, there’s a lot of chance of understanding it wrong, not to mention the misleading variable names in the example above. Can you blame the reader?
Second, the long way will have many exits.
The execution of a long method is actually done in several phases, each of which may have its own remote calls, data validations, and exceptions thrown, leading to many exits in the long method. A method that has multiple exits is, in most cases, a bad programming habit, mainly reflected in:
1. Debugging breakpoints are uncertain. For example, you make a breakpoint on a line, but when you debug it, you realize that it’s not executed because the method ended through an exit before that. Repeated attempts to find breakpoints reduce development efficiency.
2. Repeatedly build the return value. If a method has a return value, then of course the return values of multiple exits will not be the same, and they must be preceded by the same process of building those return values. If the process needs to be changed, then missing something is a BUG.
3. Some return statements are indented, which makes it difficult to read. Because when you get to this point, the layers of logic that you’ve been building up in your head are suddenly completely broken, and at some point, the method ends there. So you have to remember that all the logic in the code that follows excludes this scenario. Two or three more finishes like this might drive you crazy.
I said most of the time. So what is the rest of the case? It is mainly a validation method, such as:
public boolean validate(Order order) { if (order == null) { return false; } if (order.isCancelled()) { return false; }... return true; }There are multiple exits for this type of approach that I find acceptable.
3. Reading a long method is very taxing.
When we read a method, we construct each parameter and variable in our mind and understand how it evolves. At this time, each additional variable is an increase in the mental burden. You know, mental capacity is different from person to person, even the same person, in different mental states of capacity is also different. Therefore, if a software product or project wants to reduce the likelihood of errors throughout its life cycle, it is necessary to improve code readability — in other words, to reduce the mental burden of reading code. Code readability is part of risk control, and a long approach adds risk to a project.
How to overcome
That’s what happens when a method is too long. To overcome this, first of all, read the books I originally recommended, and second, develop your own abstract thinking, extracting multiple levels of abstract logic from specific functions, and splitting the implementation of functions into different levels of abstraction.