This is the first day of my participation in the August More Text challenge. For details, see: August more Text Challenge juejin.cn/post/698796…
As an intern in a company, I took over a module related to permissions. When a new version was coming online, this module was also separated from other modules. My predecessor carried over the old code and reconstructed it, and THEN I took over to continue to accept reconstruction and develop new permissions and functions. Start reading Robert C. Martin’s Code Clean Tips during refactoring. During this period has played a great role in guiding me.
What should the approach look like
Be short and do only one thing
Approach is to write lengthy because it do too many things, a good method should be short and clear, too long code is difficult to understand and maintain, so should as far as possible will take apart long methods, first of all to understand the meaning of the original method, then it does task split into several subtasks, each subtask to encapsulate the object-oriented thought. Also, name and write javadoc comments properly and clearly.
Abstract level
This is an easy thing to overlook, and not all approaches are on the same level. Separating methods by level of abstraction and paying attention to where they are called lends itself to the top-down code reading habit.
For example, to get a List of strings from a file, there is a method readFile to read the file and a method convertString2List to convert the string into a character array.
- Both methods are theremainIn the call
- mainIn the callreadFile.readFileIn the callconvertString2List
Don’t returnnull
The lower-level methods try to avoid returning a value of null to avoid the null-handling required by higher-level code. Null should be detected in low-level code in a timely manner, throw an exception if it is an error, or return an empty object
parameter
For methods such as completeArg, using Arg completeArg(Arg Arg) is usually better than using void completeArg(Arg Arg)
Methods that have Boolean types in their arguments should be split if they are doing two different things
For methods that take a lot of arguments, For example, String generateSql(String tableName, String idName, String eiName, String authCondition, String EI) is a method that generates SQL statements, The first three parameters, as column names, can be wrapped in a separate class. If called only in this class, you can make it private. And then use the object as the argument String generateSql(SqlArg SqlArg, String authCondition, String EI)
No side effect
Some methods have the side effect that when the method is called, something happens that the caller did not foresee. This is mainly due to non-standard naming and violation of the do one thing principle
Do not have output parameters
The output parameters are a legacy of the process-oriented method, such as the void completeArg(Arg Arg) mentioned above, which should be modified to arg.pletearg (). Most of the parameters are naturally treated as inputs, and input and output parameters can be confusing
Separate instructions from queries
For example, the Add method of Set in Java returns a Boolean type indicating whether the insert was successful. Contains determines whether the collection contains the value. Add is an instruction and CONTAINS is a query. You should avoid using Add to replace Contains. Of course, multithreading should be considered separately.
abnormal
In addition to the external API provided by the module, internal methods should use exceptions rather than error codes. Calling a method and determining that the return value is an error code violates the principle of separating instructions from queries. When you use a try-catch to handle an exception, the try block and the catch block do two different things, and it’s perfectly possible to separate them out as two methods. It’s also confusing to have multiple lines of code in a try because you don’t know which statement is throwing the exception. A try-catch statement with good error handling is necessarily clean and tidy.
Structured programming
Dijkstra’s structured programming is important for longer methods, ensuring that they have only one exit and never have a GOTO statement can make their processing logic clearer.
How to deal withswitch
The best way to avoid switch statements that make code violate the single responsibility principle and the open and close principle is to use a factory, put the switch inside the abstract factory, and use polymorphism to receive the return value.