Parameter columns with too long bad code taste and too long code taste Parameters

Parameter columns with too long bad code taste and too long code taste Parameters
1. Why is a function with too long parameters?

When too long parameter columns appear, the division of duties is unclear during programming. A function does too much and may allow the caller to input more parameters for function implementation. The second function is not properly encapsulated. As a result, the internal variables that call the function become the parameters of the function.

2. What should we do when we encounter too long parameter functions?

When we encounter a function with too long parameter columns, there are two ways to solve this problem. First, we can encapsulate the parameters of functions that are temporarily not needed in the program by reloading parameters, reduce too long parameter columns. Second, by encapsulating the parameter column object, try to put parameters with similar responsibilities together during encapsulation, which improves the cohesion of the encapsulated object.

3. How to avoid long parameter columns in normal encoding?

So how can we avoid too long parameter columns in encoding? When using SSH or Spring MVC, we will be exposed to a lot of O. We can encapsulate long parameter columns into a data transmission object, this reduces the number of parameter columns and improves code reusability.

Secondly, we can reasonably encapsulate functions. the method I often use is to compile a function and then look back at the function's responsibility scope to strip out the functions with extra responsibilities, each function has only one single responsibility. after doing so, you can extract code with high cohesion when you need to encapsulate the parameter object.

What is the bad taste of code?

The bad taste is generally from the book refactoring, such as code repetition, too long functions, too large classes, too long parameter columns, and so on.

Why is reconstruction required? There are 7 Reasons

3. Can all design errors be ruled out through reconstruction of design changes that are hard to be completed through reconstruction? Are there some core design decisions that cannot be modified through reconstruction? In this field, our statistics are incomplete. Of course, in some cases, we can refactor very effectively, which is often surprising, but there is indeed something difficult to refactor. For example, in a project, it is difficult (but still possible) to "no security requirements) the constructed system is restructured into a good security system 」. In this case, my approach is to "Imagine refactoring first 」. When considering candidate design schemes, I will ask myself: How difficult is it to reconstruct a design into another one? If it looks simple, I don't have to worry too much about the right choice, so I will choose the simplest design, even if it doesn't cover all the potential needs. But if I don't see a simple refactoring method in advance, I will put more effort into design. However, I found that this situation rarely occurs. 4. When should we refactor? A clear signal for rewriting (rather than refactoring) is that the existing Code cannot work properly at all. You may just try to perform some tests, and then you will find that the code is full and is wrong and cannot operate stably at all. Remember, before refactoring, the Code must at least work normally in most cases. One compromise is to refactor the bulk software into encapsulated small components 」. Then you can "refactor or recreate" the components one by one. This is a promising method, but I don't have enough data to write good guiding principles. This is certainly a good direction for an important old system. In addition, if the project is nearing the deadline, you should avoid restructuring. At this time, the productivity gained from the reconstruction process can only be reflected after the deadline, and at that time I will not give it. Ward cunnhan has a good opinion on this. He described unfinished restructuring work as "debt 」. Many companies need to borrow debts to make themselves operate more efficiently. However, if you borrow a debt, you have to pay interest. The extra cost of maintenance and expansion caused by overly complicated code is interest. You can afford a certain amount of interest, but if the interest is too high, you will be overwhelmed. It is very important to manage your debt. You should restructures it at any time to repay part of your debt. If the project is very close to the deadline, you should not be distracted by refactoring because there is no time. However, the experience of multiple projects shows that Refactoring can indeed improve productivity. If you don't have enough time at the end, it usually means you should have reconstructed it. Bad code 1. Repeated code. If you see the same program structure in more than one location, you can be sure to combine them into one. 2. Long functions. The shorter the function, the longer it will survive, and the better it will survive. 3. Long class. If you want to use a single class to do a lot of things, there will be a lot of instance variables in the class, and repeated code will come soon. 4. Too long parameter columns. Too long parameter columns are hard to understand. Too many parameters may cause inconsistency and are not easy to use. Once you need more data, You have to modify it. 5. Divergent changes. Once I modify the software, I want to modify it only in one place. If I cannot do this, the bad taste will pop up. 6. Smoke bullet modification. Once the software is modified, you must make small changes to the interior of multiple classes, and the bad taste appears. The function is more interested in a class than in its host class, and the bad taste appears.