This article discusses coding style, principles, and art.
As for how to code to implement the functions and performance of the system, how to design the architecture, how to improve ease of use, how to collaborate in teams, and how to manage projects, these are all beyond the scope of this article.
This article also doesn't talk about where braces should be placed, how code should be indented, and whether or not to put spaces around operators, although that's also important.
It is recommended that programmers with more than 7 years of coding experience read this article. It is difficult for programmers with too few years of programming to understand this article.
If you've been coding for more than 15 years, but this article doesn't resonate with you, it's advisable to think about your suitability for programming.
All goals of coding style
1. Code is easy to read
2. The code is easy to change
that's enough.
And it's hard to do.
most important tips
1. Small function; (note that this skill comes first)
2. Small files, small classes; (small things, easy to read, easy to change)
3. Do a good job of unit testing! (Everything is measured, you dare to change)
4. Less comments; (increase expressiveness! Code that makes people understandable at a glance does not need comments)
5. Eliminate duplication. (repetition is always ugly)
If you can't remember so many, just remember one: small functions.
seven habits
1. Keep it simple
"Small is beautiful".
Let me tell you a secret, even if you don't know how to code, you can easily and accurately judge whether a person is a programming expert.
You just have to look at his code a little bit.
If most of the functions in his code are within 20 lines, this is a master.
If it is basically within 10 lines, this is a top master.
If it's all around 3 or 4 lines, it's a master.
If there are a lot of functions with more than 100 lines, this is a novice, low-hand.
Similarly, looking at the length of each file in his code, it should be mostly within 200 lines or 400 lines, which is normal, although it is impossible to directly judge whether it is a master.
But if it is more than 2000 lines at every turn, this is a novice and a low-handed player.
Roughly speaking, experts can do:
1. Small functions, small files, and small classes;
2. Small unit test cases.
3. The function has as few parameters as possible.
The ideal number of function parameters is 0, followed by 1, then 2, and should try to avoid 3 or more.
The fewer parameters, the better the test, and the less likely it is to get the order of the parameters wrong.
(To reduce parameters, consider encapsulating into a class.)
How to do this? As long as you are conscious of keeping it lean, you will always do it.
Any file, a function, as long as it feels large enough (such as more than 10 lines), start splitting.
Here is an example:
The left side of the above figure is a function of 15 lines. After finishing, it can be written as the right side, but it is still not enough.
The code block of each color on the right should be completed by a function, so the function on the left will eventually become 4 lines. (each line is a function call)
Similarly, if you see something more complicated, just abstract it, simplify it, and make your program look very concise.
This is the practice of the KISS principle. (Keep It Simple, Stupid)
It is also practicing the principle of "loose coupling and high cohesion". (A small function, small class, must be highly cohesive)
2. Improve expressiveness
Write clean, readable code.
The code written by a high-performance person, even after 10 years, when he has forgotten all the code, as long as he needs to take it out, he can easily understand it.
I write code, never for others to see, I am just afraid of forgetting it myself.
I don't have a good memory, and I never rely on my memory, so I have to write very readable. I can't stand the feeling of disgust that comes from not understanding my own code. (Not to despise the current self, but the previous self)
"The code should be written in a way that minimizes the time it takes for others to understand it."
How to do it? Let's talk about 5 points.
1. Make the code read like natural language. (Keep practicing this)
2, attach great importance to the naming of variables and functions, to be clear and unambiguous.
所有函数命名，都以动词为开头。（类名用名词）
不要怕命名长，只要有助于理解，长点没事。
慎重选择用词，考虑不会让人误解。for example:
The above code is a copy of the string. If the parameter names are changed to source and destination, it will be much clearer, and the referer will not easily get the parameter order wrong.
3. Write comments when there is really no way to express your intentions with code.
Apart from the necessary notes such as copyright and license, in most cases, I only write notes when I think I may not understand them in the future.
Under the more old-fashioned framework, comments should account for more than 1/5 of the code.
However, for the pros: in most cases, the annotations indicate a failure.
所以，在你想注释的时候，再努力一下，看能不能仅用代码就可以明白表达。
“不要给不好的名字加注释——应该把名字改好”Annotation is not code, so it is difficult to manage and test. Comments are often outdated, buggy (and hard to spot) due to the lazy nature of humans, which usually don't change with code changes.
"Inaccurate annotations are far worse than no annotations. They're full of nonsense."
4. Take care of the reader's feelings
Put similar functions together.
If function A calls function B, put A before B, and people will read it naturally. And the reader will have an expectation, see a new function, and know that it will soon be able to read its implementation.
(But my habit is: put B in front of A, because some programming languages require that a function can only call the function that has appeared before, if it is not declared. So, looking at my program, you need to look at the bottom of the file .)
Likewise, conceptually related code, put together, separated by blank lines.
Stop using the Hungarian notation that Microsoft advocates (such as szAuthor)
, it's outdated. It is good to use case or underscore to separate word names (such as deletePage)
, Hungarian notation is ugly and directly affects the reading experience.
Another example: avoid do/while statements for readability.
Do/while is an ugly way to write it. Generally speaking, logical conditions should appear before the code they "protect", which is what if/while and for statements do. And do/while puts the condition after it, which is so anomalous that when most people read do/while, they need to read it twice.
5. Don't repeat!
"Duplication can be the root of all evil in software.
"Duplication" wastes coders' time, readers' time, maintainers' time, compiles, and runs. Also, storage is wasted.
When you see repetition, rewrite it. This is a basic quality.
3. Test while writing
If the program is easy to read, it is very easy to modify.
But just being "easy to read" isn't enough.
Many programmers dare to write code, but dare not change it. They all know what it means to "involve the whole body".
So, every time you ask them to change the program, they don't look good.
Only top experts will "happy to change the program", they know that this is another opportunity to show their abilities.
How did they do this?
Their confidence comes from testing.
The higher the test coverage, the more assured you will be, and you can modify it with confidence, and even change the architecture with confidence!
The following is the methodology of TDD (from Extreme Programming)
, which is worthy of reference and reference. (To be honest, I didn't do it strictly)
1.在写功能代码前，先写一个小的单元测试。（不要写太多，否则你会没有动力）
2.运行所有测试（先看这个测试是否能工作），测试应该失败。（因为还没有写生产代码）
3.编写仅仅能通过这个测试的最简单代码。（先不用写很好，后面还会重构；也不要写更多，因为其他还没写测试）
4.通过所有测试。（注意是所有测试，这保证了一切都是对的。）
5.根据需要重构，每次重构后都测试。（始终保持一切都是对的。）
6.重复上述循环。（测试和编码应该是小型和渐进的）Test cases should have this structure: setup, execution, validation, and possibly cleanup.
Test cases should be as small as possible, doing one thing at a time.
Stick to the TDD principle and you will have test code with high enough coverage, otherwise not necessarily.
Note: "Test code is as important as production code. It's not a second-class citizen. It needs to be thought about, designed, and taken care of. It should be kept as clean as production code."
Of course, writing test code itself has a cost, but you have to think about it, is it worth it?
Fourth, clean up from time to time
Everything, if not maintained, will always get dirty and go bad. (This is the "entropy increase" that many people like to say in the past two years)
The same goes for the code. (unless you never use it again)
So, every time you change your code, make it cleaner.
As the Boy Scouts of America rules: "Let the camp be cleaner than when you came."
Note that the premise that you dare to clean is that you have enough test cases.
Every time you clean up, tell yourself that you will do yourself a huge favor: you will avoid huge troubles down the road.
This can be used in any area of work and life, including your mind.
5. Maintaining two diametrically opposed thinking at the same time
A lot of thinking has diametrically opposed opposites and has its fans.
For example, some people say that WEB3 is the future, and some people say that WEB3 is garbage.
Some people say that the company needs humanized management, while others say that it must be wolf-like management.
Two or three more examples:
1. Should I program top-down or bottom-up?
The correct answer is to use both types of thinking.
2. Write the code first, then write the test; or write the test first, and then write the code?
See for yourself.
3. The readability of the "ternary operator" is also debatable.
Proponents say it's terse, with only one line; opponents say it can be confusing to read.
Is the following so good,

Or is the following better?
Correct practice: use if/else by default, only use the "ternary operator" in the simplest case.
The advantage of maintaining two kinds of thinking is that you can always practice, test, and reflect on these two formulations, find a balance between the two extremes, find the applicable scenarios for each, and find a way that is more suitable for you.
This will make you more relaxed and flexible.
Even, don't blindly pursue "small is beautiful", it's okay to be bigger occasionally.
6. Know what not to do
The best code to read is no code.
If there is one already available, don't do it yourself.
If you can't use it now, don't write it yet. (YAGNI Principle: You Ain't Gonna Need It)
Every line of code you write should be tested and maintained.
You save yourself time, you have more important things to do.
7. Renew yourself
Since the appearance of FORTRAN in the late 1950s, people have continued to learn and grow in terms of programming ideas.
People first realized the importance of encapsulation. The designers of the ALGOL language adopted the program blocks marked by Begin...End in ALGOL60, so that the variable names in the block are local, so as to avoid them and the variables with the same name outside the block in the program. Conflictingly, this is the first attempt in a programming language to provide encapsulation.
In the late 1960s, with the introduction of "Program Structure Theory" and "The Harmful Theory of GOTO Statements", it was proved that the logical structure of any program can be represented by sequential structure, selection structure and loop structure, and the structured programming was established. Thought, this makes the program easier to maintain.
In the 1980s, the idea of object-oriented programming gradually matured after 20 years of research and development, and a large number of object-oriented languages appeared one after another.
In February 2001, in Wasatch Mountain, Utah, USA, 17 practitioners from various agile methods reached a consensus: "Agile Manifesto", which proposed twelve agile principles.
The tenth principle is closely related to this article:
Simplicity is the essence of agility, it's the art of minimizing unnecessary work.
Simplicity--the art of maximizing the amount of work not done--is essential.
Then, design patterns, refactoring, became popular.
And then, with CI/CD, with Devops.
Programmers in the past did not understand this.
If you are engaged in IT, you will find that programming ideas, methods, languages, and tools are endless and endless.
A true high performer never stops learning and never stops updating himself.
Because there will always be something better.
outside of programming
When I named these 7 habits, I deliberately used generic terms.
These highly abstract theories can be used in other fields.
1. Keep it simple
2. Improve expressiveness
3. Test while writing
4. Clean up from time to time
5. Keep two diametrically opposed thoughts at the same time
6. Know what not to do
7. Update yourself
These can also be used in writing, work, life and being a person.
Mature people understand this.
Figure | Seven Habits of Highly Effective Programmers
This article pays tribute to Stephen R. Covey with the title and illustration for his divine book The Seven Habits of Highly Effective People.
This article cites mainly from the following two well-known works:
Robert C. Martin. Clean Code. People's Posts and Telecommunications Publishing House.
Dustin Boswell, Trevor Foucher. The Art of Writing Readable Code. Mechanical Industry Press.
Text｜Wei Jianvan