[Declaration] If you need to copy, spread, please attach this statement, thank you. Original source: http://morningspace.51.net/, MOYINGZZ@etang.com Note is the lifelong partner of the source code, which is unquestionable. She is usually used to explain the control flow of the source code, or the class, function, and variables, etc., to reflect the intent of the program writing, purpose. Regarding the problem of comment, inquiring, "When?", "What?", "How to write?". For some programmers, write comments seem to be a very feminine thing. Imagine how you are willing to interrupt your thoughts to consider the writing of your comments; how to get your head after considering add a comment after completing the coding? This situation is easy to develop habits. This article is prepared to provide some general recommendations, but do not involve specific annotation formats and methods. These content can be found in related books and articles. Note You should first not insult the intelligence of each programmer, some obvious explanations seem to be omitted, and do not simply repeat the information already expressed because it is extra. It should not be regarded as a formal task or responsibility, and this is not a simple passive behavior. Comments should be easy to read and understand, this is not only beneficial to yourself, including others, your successor may take over your code. It is the most terrible thing that is the so-called believer. A good comment is actually required by the text, it should be clear, simple, accurate, valuable. The frequency of comments should be appropriate, she only appears in the required place, and some of the content is not too much. Excessive annotations will divide the code to be bracked to affect the smoothness, thus affecting the coherence of reading reader's ideas. The annotation of the large section may often be ignored by those acute sub-readers. He is so prefer to go to the hard, but it is a real code. As time goes, it is possible to slowly change its original face, a careful, or lazy programmer, it is very likely to forget the consistency of the timely retention of code and annotation. Such a mistake may be a good programmer, people are not holy sages, and they are cooked. In fact, keep this consistency, it is an extra cost other than the code, it is necessary, but it also needs to pay a cost. If you try to consider the cost of reducing the subsequent maintenance, this synchronization is relatively easy. You can spend some energy on maintenance, this is a good thing, I believe anyone will agree, including you and your boss. An obvious example is: Avoid reference to variable code information in the comment, which is an important cause of code and comment. Remember that notes are not intensive, this is similar to the document. If you don't have the precautions for the use of a function written in the comment, the program can still be smoothly executed until you have a fatal error, and you have to pay a painful debug for this. Therefore, if you want to force constraints, you should use the function and characteristics of the programming language itself as much as possible, and strive to let the compiler before generating an executable code, or use the assertion (askERT) to clarify the facts. . Standardized annotations can also help automatically generate some development documents, perhaps this can be left part of your part of the development document. Java DOC is an obvious example. In addition, comments can also have some additional roles. For example, when writing the program, for the currently not implemented code, the comment can be used as a way of help or a memo to add code here.
