Martin Fowler: Any fool can write code that computers can understand. A good programmer is one who writes code that humans can easily understand. Close your eyes and think about what is good code? You probably have a list of words floating around in your head: clean, neatness, proper naming, well-annotated, high cohesion and low coupling… Everyone wants to write good code because looking at good code is like looking at a woman with good features and feeling good, and looking at bad code is like looking at rotten food and smelling bad. Most people write code that can’t be called good code. On the one hand, due to their limited skills, on the other hand, they may not be able to tell the difference between good code and bad code.
Bad taste: Long Method
In short, an overlong function is a function with excessive length, including horizontal and vertical. Why is an excessively long function a bad taste? Horizontal too long will not be able to see the role of this line of code at a glance, need to use the mouse slowly drag behind, I believe that small screen partners often encounter this problem, the process of dragging will seriously affect the efficiency of reading code. Vertical length is actually the emergence of a large function, a function of too many lines, making the function difficult to read, code modification is difficult. So how do you solve the problem of excessively long functions? As for the horizontal length problem, it is common to configure the maximum width in the IDE in advance, such as 80 characters or 120 characters (depending on the internal company specification), and then format the code. For example, we can write Java8 stream chained expressions that are very long: List nodes = list.stream().filter().filter().map.filter().collect(Collectors.toList()); // It can be very long. I’m going to wrap it so it’s easy to see. List nodes = list.stream() .filter() .filter() .map .filter() .collect(Collectors.toList()); The problem with the vertical length is that the method or function is not single enough, and there are too many functions in one function. The refactoring approach is simple: Extract Method, actively Extract functions or methods, hide details and keep responsibilities simple.
Bad taste: Large classes
Classes that are too large are often referred to as God classes, and God classes are generally defined as maintaining so many functions (in violation of the single responsibility rule) that even God cannot read your code. The six principles of design patterns include: Single Responsibility Principle, Open Closed Principle, and Liskov Substitution Principle. Principle of Demeter/Interface Segregation Principle The six initials combined are SOLID, with two L’s acting as one. So how do you tell if a class is god? Generally, a class satisfying the following three conditions at the same time is a God class: (1) Capsules Providing Foreign Data in CPFD (CPFD) references Data from multiple unrelated classes (modules). (2) Weighted Operation Count (WOC) class the sum of cyclomatic complexity of all functions exceeds 65. TCC < 1/3 categories needed to have the characteristics of low Cohesion (the ratio of directly related methods in categories to all methods was less than 1/3), that is, fewer private methods. Why are oversized classes a bad taste? Too big a class takes on too much responsibility and often has a lot of duplicate code that you can’t easily spot, which is basically the beginning of a bad taste. Classes that are too large to be inherited by subclasses can lead to other bad flavors, such as legacy gifts. How do you solve the problem of large classes? See if any of the attributes are associated with the Class. If so, use Extract Class to abstract the associated attributes into a new Class and Move all operations related to those attributes into the new Class. See if there are any functions or methods that have sibling relationships, and if there are any that can be extracted into subclasses that inherit from their parent class. Aggregating similar behavior methods into a single class and splitting them into multiple classes further decouples the release calls. Repeating the above approach, a large class can be broken up into smaller, single-responsibility classes.
Bad taste: Duplicated Code
Robert C.Martin: Repetition may be the root of all evil in software. Duplicate code is usually caused by copy and paste. During requirements iterations, it is common to copy the original code so as not to affect existing functionality and then rush to launch. So why is repetitive code a bad taste? The most direct drawback is that if you want to change a piece of code logic, you may miss it, and you may need to change it several times to make sure it’s all changed. How to solve the problem of duplicate code? The following scenarios are described in combination with code practices. Scenario 1: Class A {public void method1() {logic1 logic2 logic3} public void method2() {logic1 logic2 logic4 }} Refactoring: Abstracts the logic common to the two methods. Class A {public void method1() {baseMethod(); logic3 } public void method2() { baseMethod(); Logic4} public void baseMethod() {logic1 logic2}} Scenario 2: Two subclasses with the same parent have the same expression class A has A method1, with three logical sections. Class A extend Base {public void method1() {logic1 logic2 logic3}} Class B has A method2 and also has three pieces of logic. Class B extend Base {public void method2() {logic1 logic2 logic3}} Refactoring: Abstractions duplicate code into a method in the parent class, and the differences are implemented by the subclasses themselves. After the refactoring: class Base { public void baseMethod() { logic1 logic2 } } class A extend Base { public void method1() { baseMethod(); logic3 } } class B extend Base { public void method2() { baseMethod(); Logic3}} Scenario 3: Duplicate code occurs in two unrelated classes. If duplicate code occurs in two unrelated classes, consider abstracting the duplicate code into an independent common class or utility class, which can be called by the appropriate party in combination. The code samples will not be repeated here. They are similar to scenarios 1 and 2, but you are smart enough to understand.
Bad taste: Long Parameter List
Global variables are evil things. Data is shared and can be modified by each thread. Too many can easily lead to uncontrollable programs, so people like to pass variables as line arguments, and the argument list gets longer and longer over time. Why is a long parameter column a bad taste? Too many method arguments can make your code very unreadable, and if you have multiple overloaded methods with too many method arguments, it’s hard to tell which one to call when you’re writing code. When a method needs a new function, a new method parameter may be added each time, causing the caller to have to re-adapt each time. How to solve the bad taste of long parameter columns? Multiple arguments can be encapsulated in a SINGLE DTO object, and objects between methods pass through objects rather than excessively long arguments. Data Transfer Object (DTO) is a software application system that transfers Data between design modes. In particular, it is important to note that long parameters can be justified in some cases because they can be used to avoid dependencies. In coding practice you can look at the long parameter method, and if the method changes a lot then you should consider refactoring the method. Basic principle: after three things, three reconstruction.
Bad Taste: Shotgun Surgery (Shotgun Modification)
Why is bullet-busting a bad code smell? If you need to change a small feature, you need to change it in many different classes. First, it is difficult to find it all, and second, it is likely to miss it. This problem is commonly referred to as a scatter-bullet change. public class A { @Value(“${db.mysql.url}”) private String mysqlDbUrl; }
public class B { @Value(“${db.mysql.url}”) private String mysqlDbUrl; } If you have multiple classes that use db.mysql.url, you may need to change mysql to Oracle later. What’s the solution to the code stink of scatter-bullet modification? You can use Move Method and Move Field to put all the code you need to change into the same class, or create one if you don’t already have one.
Bad taste: Speculative Generality
At work, I often hear developers say: I worked overtime yesterday and modified the order module, so I can… You can applaud this: Great, the extensibility of the feature template was reserved in advance. But don’t be too quick to malfunction, you see the technical director’s face is black, why? This friend’s code can be a bad taste: talk about the future. Why is talking about the future a bad code smell? The Internet needs rapid iteration and update. “future can” means that the present is not needed. Sometimes excessive abstraction and reserved expansion will make the system difficult to understand, and may carry the burden ahead of time. Talking about future possibilities in code can bog your team down. Every time there is a business change, developers will consider all future possibilities and reserve enough extension interfaces, which can greatly increase code complexity and slow down a requirement that could come online quickly. What’s the solution to the bad taste of code that talks about the future? There is a principle in code architecture called Simple Design. There are four principles to consider when implementing current business code: pass testing, reveal intent, eliminate duplication, and minimize elements. When writing code for the future, do this: (1) remove arguments, code, and method calls that are useful for the future. (2) Modify the method name to reveal the intention of the current business scene and avoid abstract technical descriptors. If the changes to the code are truly inevitable, then it is advisable to keep them. Talking about the future is more about developers making assumptions about the future that lead to code modules being over-designed.
Bad taste: Comments
Clean Code lists some common bad comment smells: mumbling redundant comments misleading comments compliance comments journaling comments nonsense comments Using comments to explain variable meanings comments marking location comments class attribution comments Commented out Code Why is too much comment a bad Code smell? Good comments can help developers read and understand code quickly, while too many or bad comments can reduce code readability. In the development practice, students often modify the code but the annotation is not synchronous modification, the implementation of the code has been inconsistent with the annotation content, which is easy to mislead. What’s the solution to the bad taste of too many comments? (1) If the code block is no longer used, please delete it directly and do not use comments. (2) The naming of methods and variables should be known as far as possible, and should not be explained again with comments. (3) If the short comment does not cover the meaning of the method, it may be that the method has different responsibilities. Consider refactoring the method.
Conclusion:
The article lists several common code bad taste, hope everyone in the work of coding practice, strive for everyone can write good code, so that there is no difficult to read code. If you want to learn more about bad Code, I recommend reading two books: Refactoring: Improving the Design of Existing Code and Clean Code.