["Clean Code Agile Software Master's Skill"](https://www.amazon.co.jp/Clean-Code-%E3%82%A2%E3%82%B8%E3%83%A3%E3%82 % A4% E3% 83% AB% E3% 82% BD% E3% 83% 95% E3% 83% 88% E3% 82% A6% E3% 82% A7% E3% 82% A2% E9% 81% 94 % E4% BA% BA% E3% 81% AE% E6% 8A% 80-Robert-C-Martin / dp / 4048930591) and briefly summarize the rules that I found important to keep my code clean. It was. I think it's important to make your code extensible and maintainable so that others can read your code easily.
** Method is as small as possible (3, 4 lines) ** One method and one role. If it contains multiple processes, disassemble it.
** Up to 1 or 2 indents ** Nesting with if and for statements should be reduced.
** Align the level of abstraction in the method. ** **
** Easy-to-understand method name. ** ** So that even those who read the code for the first time can understand what it represents.
** Fewer arguments. 0 is ideal, 2 or less. ** ** boolean is not an argument. Passing boolean as an argument means that there is a conditional branch inside.
** Eliminate side effects. (Hidden process) ** Eliminate hidden processing that cannot be understood from the method name.
** Make it understandable without looking at the caller of the function. ** ** So that you can see what you are doing with the method name.
** Cut out the contents of try catch into a method. ** ** If you use try and catch, it will be hard to see.
** DRY (Don't repeat yourself) principle. ** ** Do not repeat the same code.
** Conditional expression encapsulation. Be as positive as possible. ** ** Do not use! Or not ◯◯ as much as possible.
** Write variables and private methods near where you use them. ** ** It is easy to see because there is no need to scroll greatly in the vertical direction.
** Use descriptive variables. ** ** Give a variable name to the value in the calculation process.
** Boundary condition encapsulation ** Extract the boundary value used in the conditional expression as a variable name.
** Arrange the methods in order of abstraction level. ** **
** Do not use comments as much as possible. ** ** Make it easy to understand by method name, variable name, and class name.
The procedural type makes it easy to add functions later. Object-oriented makes it easy to add classes.
** Use unchecked exceptions. ** **
** Returns the exception class instead of the error code. ** **
** Write enough logs when you catch. ** **
** Do not return null. ** ** Null checks tend to increase. Deal with it by returning it as an empty list.
** Do not pass null as an argument. ** ** There are few methods that can handle it well when null is passed. In principle, it is better to prohibit passing null.
Make it easy to understand what you are testing.
The priority is high in order from the top. (② and ③ are about the same) ① ** Passes the tests ** The test passes. You can always verify that your code works as intended.
② ** Reveals intention ** Clarify the writer's intent with good naming, keeping functions and classes small, and applying design patterns.
③ ** No duplication **
④ ** Fewest elements (minimize classes and methods) ** Reduce the number of functions and classes.
Ideally, you should be able to read the code and see what you're doing, without using comments. I personally wanted to be able to write ** code that can be read in the same way as reading natural language ** by devising variable names, method names, class divisions, and so on. Also, if you have a test, you can take the plunge and refactor it. I want to always write enough tests, making full use of TDD etc. so that the code can be cleaned at any time. Actually, it is often difficult to take time to clean the chords, but with the "boy scout rules" in mind, ** the chords I find are cleaner than when I found them **. I'm going to reduce the dirty code.
Recommended Posts