Yes, but this is hardly an argument against using comments. There will always be a pathological case. The question is what approach will increase your chances

Yes, but this is hardly an argument against using comments. There will always be a pathological case. The question is what approach will increase your chances of success, what's least likely to lead to problems, what's the cost-risk-benefit tradeoff etc. Comments detailing the intent of a non-obvious function are valuable for maintainers wanting to figure out what's happening in the code. They are written in human-oriented business-oriented language, so they don't take effort to read. The intent of the code should not change that often. If they diverge from the code, the effort of changing them should be small enough to be worth it. Ideally they should be treated as important and if they are wrong it should be picked up in the code-review. Comments detailing just the description of what a function does, by contrast, are not valuable, since that information can be deduced from the code itself. Every time the function changes, the comment will change. Reading them is as much effort as reading the code, so if they diverge it won't be picked up as easily. There are always exceptions to these kinds of guidelines, of course, but this at least gives motivation for why I think comments should be used in this way.