A memorandum for writing beautiful code

Overview

["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.

function

  1. ** Method is as small as possible (3, 4 lines) ** One method and one role. If it contains multiple processes, disassemble it.

  2. ** Up to 1 or 2 indents ** Nesting with if and for statements should be reduced.

  3. ** Align the level of abstraction in the method. ** **

  4. ** Easy-to-understand method name. ** ** So that even those who read the code for the first time can understand what it represents.

  5. ** 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.

  6. ** Eliminate side effects. (Hidden process) ** Eliminate hidden processing that cannot be understood from the method name.

  7. ** Make it understandable without looking at the caller of the function. ** ** So that you can see what you are doing with the method name.

  8. ** Cut out the contents of try catch into a method. ** ** If you use try and catch, it will be hard to see.

  9. ** DRY (Don't repeat yourself) principle. ** ** Do not repeat the same code.

  10. ** Conditional expression encapsulation. Be as positive as possible. ** ** Do not use! Or not ◯◯ as much as possible.

Formatting

  1. ** 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.

  2. ** Use descriptive variables. ** ** Give a variable name to the value in the calculation process.

  3. ** Boundary condition encapsulation ** Extract the boundary value used in the conditional expression as a variable name.

  4. ** Arrange the methods in order of abstraction level. ** **

  5. ** Do not use comments as much as possible. ** ** Make it easy to understand by method name, variable name, and class name.

Objects and data structures

The procedural type makes it easy to add functions later. Object-oriented makes it easy to add classes.

  1. ** Law of Demeter **
    When using an object, you should not know about the inside of the object. Reduce class dependencies.

Exception handling

  1. ** Use unchecked exceptions. ** **

  2. ** Returns the exception class instead of the error code. ** **

  3. ** Write enough logs when you catch. ** **

  4. ** Do not return null. ** ** Null checks tend to increase. Deal with it by returning it as an empty list.

  5. ** 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.

boundary

  1. ** When external cooperation is required, code that does not yet exist uses the interface. ** **

Test code

Make it easy to understand what you are testing.

  1. ** One assert for one test. ** **
  2. ** One concept in one test. ** **

class

  1. ** Make variables private **
  2. SRP(single responsibility principle) One role in one class.

4 rules for simple design

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.

Summary

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.

References

  1. [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)
  2. BeckDesignRules

Recommended Posts

A memorandum for writing beautiful code
A memorandum for android application development beginners
[Rspec] Flow from introducing Rspec to writing unit test code for a model
Writing code Ruby
A memorandum to clean up the code Ruby
Make a snippet for Thymeleaf in VS Code
[Java] When writing the source ... A memorandum of understanding ①
A memorandum for creating an extended logger using org.slf4j.Logger
A memorandum to reach the itchy place for Java Gold
Oracle Live for the Code
Memorandum (task: model test code)
Create a VS Code Plugin.
[Java] Tips for writing source
Programming from 51 years old Memorandum code for network communication Socket | HttpURLConnection
Let's write a test code for login function in Spring Boot