4 ms·
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 t
by jfabre 4y ago
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 4y agoThere 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 4y agoand 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 4y ago> Refactoring it usually made the comments redundant That sounds like a nice story
- jfabre 4y agoThe 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 https://refactoring.guru/smells/comments
- grncdr 4y agoDon'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.