19th: Avoid class bloated
In most of my projects, there will always be an eye-catching category of "Fat Man". Generally, this "Fat Man" is actually one of the core categories of the entire system. the main reason is that many people add the functions they need to this class, but no one asks them to "lose weight". You can "slim down" it in the following ways ":
1. Split the class into multiple classes based on certain features (such as functions and types.
2. Merge redundant functions to minimize the granularity of functions.
3. remove duplicatesCode.
If it cannot be "thin", implement the corresponding interface to make it "looks thin". For example:
Public Class Bigboy { Public Void Foo1 (); Public Void Foo2 (); Public Void Foo3 (); Public Void Foo4 (); Public Void Foo5 (); Public Void Foo6 (); Public Void Foo7 (); Public Void Foo8 (); Public Void Foo9 (); // There are many more... }
This class has many functions, which makes it a headache for users of the class. It cannot be "thin" anymore. However, we can abstract these functions into multiple interfaces based on certain characteristics, for example, foo1, foo2, and foo3 can be abstracted into an interface:
Public InterfaceLittleboy {Public VoidFoo1 ();Public VoidFoo2 ();Public VoidFoo3 ();}
Then let bigboy implement this interface and provide a function to convert bigboy into litterboy:
Public Class BigboyImplements Littleboy { Public Littleboy aslittleboy {) Return This ;} Public Void Foo1 (); Public Void Foo2 (); Public Void Foo3 (); Public Void Foo4 (); Public Void Foo5 (); Public Void Foo6 (); Public Void Foo7 (); Public Void Foo8 (); Public Void Foo9 (); // There are many more... }
In this way, the user of the class will be bigboy of the "thin version", which greatly reduces the difficulty of use. Therefore, for users who need to use a subset of all functions of the class, we can provide an interface implementation object that contains a subset of this function.
20th: maintain code style consistency
ProgramMembers have more or less their own code styles. When we look at the code written by people with different styles, we feel a bit awkward, and even affect the smoothness of reading code, I remember a colleague used the for statement as an if statement, which is too personal as below. It is a headache to see his code.
For(; Value> 10;){...}
It is important to keep the code style consistent throughout the program. If you look at the code as a person, it will be too good. Therefore, it is best to unify program naming rules, logic processing specifications, and comment specifications at the initial stage of the project.
21st: member variables to be encapsulated
In most cases, the member variables in the class should be declared as private, and the set or get function should be added for those variables that need to be accessed by other classes. If the member variables are declared as public, the class will lose control of them! Encapsulating member variables has the following benefits:
1. Perform validity verification or other preprocessing operations when assigning values to member variables.
2. Perform secondary packaging when the value of the member variable is returned. When the variable is unavailable or not initialized, the default value is returned.
Adding the set and get functions to member variables is a very tedious task. Many people may feel that the public member variables are more convenient. However, from the perspective of maintainability and scalability, it is worth adding set and get functions. In eclipse, the set and get functions can be automatically generated, which is very convenient.
22nd: replace complex conditions with self-explanatory variables
Complex Conditions with deeper nested hierarchies such as if judgment and without comments greatly increase the logic complexity of the program and greatly reduce the readability of the Code. For condition determination with many sub-conditions, you can introduce a temporary variable with self-annotation for each sub-condition to reduce complexity. For example, the following figure shows whether a logon user can access the background management interface of the website:
If(Username! =Null& Username. Equals (name) & (userstate! = Inactive | userstate! = Delete) & userpassword! =Null& Userpassword. Equals (password) & (usergroup = "manager" | usergroup = "root")){...}
The modified version is as follows:
BooleanIsusernamevalid = username! =Null&&Username. Equals (name );BooleanIsuseractive = userstate! = Inactive | userstate! =Delete;BooleanIsuserpasswordcorrect = userpassword! =Null&&Userpassword. Equals (password );BooleanIsuserhasauth = usergroup = "manager" | usergroup = "root";
If(Isusernamevalid & isuseractive & isuserpasswordcorrect &&Isuserhasauth ){...}
The second method not only makes condition judgment more readable, but also can reuse sub-conditions.
23rd: avoid repeated code
Repeated Code is one of the heavyweight players who damage the maintainability of the program. A large number of repeated code will increase the amount of code, and it is also cumbersome to modify repeated code, after a bug is changed, the code that is duplicated with it must be modified at the same time. Therefore, a bug is introduced. When someone modifies a code and forgets to modify other code that is not duplicated, the bug will appear. Therefore, if you want to copy a code segment, you must first consider generalization of this code segment.
24th: add comments
I remember that when I was working in the first company, many programmers in the company had a code annotation rate of around 40%. Generally, they first wrote comments and then wrote code, because annotations are also a document. Many people think that writing comments is a waste of time or unnecessary, so their code is not green or just a few stars. If the code is complex, other people may think that this part of the code is much harder than the author of the Code. Annotations help others quickly understand the code they write.