I don't think you understand what I'm saying. The people who maintain the system are not helped by incorrect information. The information describing how the co

I don't think you understand what I'm saying. The people who maintain the system are not helped by incorrect information. The information describing how the code works in comments is invariably incorrect. None of the tools we usually employ (unit tests, regression tests, compilation, etc.) apply to the comments, and describing the HOW of code in comments breaks the DRY rule unless the comments ARE the code. Now, as I said, sometimes you need to describe intent. Most of the time, that is better done through liberal use of functions, purpose-specific types and function names. For example: In C, there are multiple types of integers defined that all reduce to roughly the same types: size_t, ptrdiff_t, etc. Does the compiler care if the type is unsigned int or size_t? No. Apart from the portability reason for using these types, the other is to describe intent. A variable of the type size_t should store a size. Now, we could make the variable an unsigned int, and in a comment say that "this variable stores a size". But will this comment stay in sync with the code, when the variable later changes to a ptrdiff_t because it is now used to compare pointers? No. The comment won't get changed, because humans are fallible, and changing the comment would require making the same change in two places, one of which is ignored by the toolchain.