Interpretation of code Daquan (6)

Interpretation of code Daquan (6)

 

Today, I spent some time reading two more chapters: Chapter 1-document and Chapter 2-notes. I thought it would be easy to look at it. while reading it, I felt that a lot of code I wrote was really rubbish, and there were a lot of bad smell. These two chapters are actually a core issue. To write comments, you do not need to write comments. I don't want to discuss them too much, but how to write comments is a problem for us.

I have summarized the following points:

1. Do not write useless comments

For example, if (Var = 0) // If the variable is equal to zero

This is useless because it does not reflect more information than the Code itself. Better:

If (Var = 0) // if no data is read

Annotations are specific business rules.

2. Use the PDL mentioned in the previous chapters (program process description language), but I still think that there is currently no good tool to use.

3. Special cases must be described. For example, if you call a function with a specific exception, you must explain the cause of the exception.

4. Note the special constants. Although constants or macros are generally recommended in popular language manuals, it is best to add a line of comment after the definition so that others can understand why you need to use the constant.

5. It is very interesting that you are not recommended to use beautiful comments, but difficult to maintain, in this book. Many programmers like to add a text logo before the code, but it takes some time for maintenance.

6. Description of the algorithm. For a complex algorithm, it is best to write some basic information. Do not "decompile" your algorithms from the code.

Finally, exercise more and don't let the comrades watching your code swear. Of course, your code is not an exception for people to understand. Haha.