You can’t be too obvious when writing code. Good names, good code structure, unit tests and comments are not mutually exclusive. And comments are the cheapest part of all of that. Commenting what a method does takes a fraction of the time that good code structure or unit tests take, so adding a comment is rarely not worth the effort.

Why would people be better at judging if something needs a comment than at judging if something needs a better name or refactoring? Asking people to skip that judgement step and comment everything just gives you a bunch of useless boilerplate comments. That trains everyone reading that codebase to ignore comments because they are almost always useless anyway.

Again, who is asking them to skip judgement? I am saying, do comments additionally.

And forcing programmers to do anything they don’t understand or are against will always result in useless results. I’ve seen enough unit tests that don’t actually test what the tested code does. I’ve seen nonsense comments. I’ve seen naming that “follows” the guideline but is totally useless or even wrong. I have even seen code that was implemented in spite and where the code superficially checks all the boxes but is totally terrible once you peek beyond that. Same goes for the whole process. If a programmer doesn’t care for code reviews, you get nothing by forcing the programmer to do them.

Does this mean all of these things are useless, just because programmers can purpously sabotage them and find loopholes that fit the guidelines? I don’t think so.

At least this we can 100 % agree on. Documentation should be as close as possible to the code. (I just think most of the time that place is in the name of things, not in an actual comment.)

If you can fit all the information about what something does plus all the specifics, edge cases and non-obvious things in maximum 4 words, then yes. Otherwise comments are the way to go.