[jfabre]

The problem with this argument is that it's implying that there is no such thing as clear code. Sure some people think their code is clear when it is not, but that shouldn't stop you from striving to write clearer code.

A long time ago, I had a tendency to write comments to explain code that could be simplified. Refactoring it usually made the comments redundant.

Comments are still very useful when the why is unclear.

[TedDoesntTalk]

There is a culture that the l33ter the code, the more senior I am. So, many people will never refactor code to make it simpler to read. It affects their ego. In fact, I've seen the opposite: simple code refactored into more complex (not by the original author). The mindset: if it's more complex, it must be better.

Java example: rewriting non-stream collections code to use lots of chained streams. Using lambda functions when not needed. Rewriting case labels to use case lambdas. etc.

[projectazorian]

and don’t forget the implicit corollary - if you don’t understand it that just means your IQ is too low, find a job somewhere else noob…

[baby]

> Refactoring it usually made the comments redundant

That sounds like a nice story

[jfabre]

The fact that you don't believe me blows my mind a little, not going to lie. Maybe this will convince you a little more? https://refactoring.guru/smells/comments

[grncdr]

Don't be too hard on them, they're only a baby after all.

More seriously, I agree with you 100%. Many, many, times I've stopped halfway through a writing an explanatory comment and refactored the to make the comment unnecessary.

This habit was formed by realizing that most people (including me) don't read comments half as carefully as they read code. So if you want something to be noticed and understood, you better put it in the code.