Article directory
Why write clean code
Whether you are a newcomer to the industry or a veteran who has been developing for many years, reading this blog, you must have encountered "ancestral code" (some people also call it a mountain of shit, which is rough but not rough) and have a headache. Every modification to the code affects two or three other codes. Every time you add or modify the code, you have to be aware of the mess. Otherwise, as the mess gets bigger and bigger, it will never be cleaned up. Finally helpless. I would rather rewrite this function myself than touch it. Being held back by ancestral code, developers are under deadline pressure and have no choice but to continue to pile up chaos. In fact, creating chaos will not help you meet the deadline. As chaos increases, team productivity continues to decline toward zero. The only way to maintain and improve efficiency is to always keep the code as clean as possible.
name
worthy of the name
- Choosing a good name takes time, but the time saved is more than the time spent.
- If the name needs to be supplemented by comments, it is not worthy of the name.
make meaningful distinctions
- If the names are different, the meanings should also be different.
For example: add and insert
both mean to add. We need to try to keep the usage consistent when using it. We cannot use insert to mean adding in the next method of using add. - Nonsense is redundant.
Example: The word Variable should never appear in a variable name, and the word Table should never appear in a table name.
Class name, method name
- Class names and object names should be nouns or noun phrases.
Example: Customer, WikiPage - The method name should be a verb or verb phrase.
Example: postRequest, deletePage
function
short
- The first rule of functions is to be short. The second rule is to be even shorter.
- Each line should not exceed 150 characters, and the total length of the function should be capped at 20 lines.
- What it should be: Every function is self-explanatory, every function says only one thing, and every function takes you to the next function in turn.
only do one thing
A function should do one thing, do it well, and do one thing only
Comment
Annotation type
- Line comments
As shown below, each line of code uses comments to describe clearly what is done.
- Block comments
are as shown below. Add a comment description on a method or a certain logical operation.
good comment
- legal information
- Informative comments
- explanation of intention
- interpret
- explain
- TODO comments
bad comments
- Mumbling to oneself, redundant comments, nonsense comments
- misleading comments
- Log comments
- commented out code
Format
Purpose
Code format is about communication. Features written today are likely to be modified in the next version, but code style and readability will affect maintainability and scalability.
vertical format
- Use a blank line between the import declaration and each function.
- Variable declaration, variable declaration should be as close as possible to the location where it is used
- Entity declaration, entities should be declared at the top of the class
- Related functions, if a function calls another, they should be put together, and the caller should be placed above the callee as much as possible.
landscape format
Use spaces to connect closely related things together and separate weakly related things (formatting code, idea shortcut key: ctrl+alt+L)
team rules
Every programmer has their own favorite formatting rules, but if you work in a team, the team has the final say. A group of developers should agree on a formatting style, and every programmer should adopt that style.
Summarize
Most of the content shared today comes from the book "Clean Code". If you want to know more methods and techniques of clean code, you can study this book in depth, and you will benefit a lot.
The above is the content shared today. If you find it useful, you can follow it and give it a like.