That's a very common position, but my experience shows me if the comments are not in line with the code that is usually a very good hint that the code will be buggy. It probably has been changed in such a hurry that the comment was forgotten, which doesn't bode well for the code quality.

You're not wrong, but comments are bad practice because they allow you to write code you have to explain in a comment. In my opinion comment-less code works really well with SOLID because it forces your developers to code clean and decoupled.

I've yet to be in a "oh this bit needs a comment" moments where the code couldn't be improved significantly to make it both better and more understandable.

Counterpoint for me: V8 source code. It's well written, and easy to follow when you know what you're looking at. But some comments would greatly improve the discoverability for new contributors.

Unfortunately code quality tends to be on the bottom of customer happy list.

I also had the "pleasure" to work in a few projects where it wasn't even on the list, beyond a few powerpoint presentations.

> That's a very common position, but my experience shows me if the comments are not in line with the code that is usually a very good hint that the code will be buggy.

An example might help but to me bad code is code that repeats itself which includes comments. To me, comments should only be used for high level explanations (e.g. architecture, algorithms, public API) and when the purpose of code is non obvious (e.g. weird bug workarounds, optimisations). The vast majority of comments can be removed by rolling their contents into better function and variable names.

IDEs can also mess with comments because they don't parse it as code. A simple extra linebreak added and your code breaks.

Not true when the comments are mechanically checked for correctness.