The more comments, the worse the code -- this is by no means a buzz

"The more comments, the worse the code.
How is the famous Engel coefficient expressed?
"The higher the proportion of food used, the poorer life"
The first time we saw this sentence, we were not equally surprised and incomprehensible.
From another point of view, it is true that my program will not become a bad code without writing a line of comments? Oh, if you live on a poor online, even if you eat only one steamed bread every day, the rest of the money will be used to visit exhibitions, music conferences, etc ......, So are you rich? No, you are still poor and thin.

So what is the true significance of this sentence? Or is it useful to us?
Next we will discuss the introduction.

Someone read my code, complained that I had too few comments, and told me that the comments should be half of the source file, or even 2/3.

I was surprised. Do you really need so many comments? Visit their code. Indeed, there are a lot of comments, which are undeniable. Some of them are really indispensable for the program, but more of them are as follows:
/*************************************** ****************
* Function name: iprsenddatabycom
* Description:
* Send data by com device
*
* Author: James
*
* Inputs:
*
*
* Return:
* None
*
* History: <History of function creation and modification>
* NAME | DATE | REMARKS
*--------------------------------------------------------
* James | 2003-8-14 | Created initial version 1.0
*
**************************************** ****************/
Int iPrSendDataByCom (OINT iComPort, unsigned char * pbuf, unsigned long size)
{

I can't see how useful these 20 lines of comments are.
The function name is included in the function definition. Do you need to repeat it again?
The most important function description is simply three letters more than the function name;
The input does not explain the meaning of the three parameters. Why?
The returned value is irrelevant to the function definition;
Only the author's information and the modification record are of little significance. But does this mean that every function has such a big hat? There is also a line of ****, you can not write a few words, they will become ugly because they cannot automatically wrap.
Obviously, formalism! However, considering that this is the code in the company, it is understandable to meet the requirements of some people.
However, some of the most common idiom cannot be understood? How do I add a bunch of comments next to passing parameters to a callback function? Do I need to explain the basic usage of semphore in the source file? Alas! Who has seen so many comments on the circuit schematic? We learn various unit circuits first. After learning about their specific functions, we can learn more large-scale circuits composed of these unit circuits, when you look at the circuit diagram, how can you achieve current amplification?" I believe that the four seats are speechless. Why? Because it is a amplifying circuit! Do you need an explanation? If you really need to explain it, go to analog circuit.
In addition, what makes comments so popular?
That is
Distorted Design
Although this design can solve the problem, it is contrary to the thinking process of a normal person. Therefore, it requires a lot of comments in the code to correct people's simple and direct ideas, this is the code that I am most afraid of. I am afraid that I will teach them badly. A good design must be easy to understand. A easy-to-understand design naturally does not require too many comments, the most unfortunate thing is that, due to the relationship between time, You can't rewrite them, and you can only do what you hate.