Agree. However, there's one exception. Sometimes we do stuff because of something else ,like DB limitation, 3rd party config, etc. Adding a comment to explain "WHY" you did something is helpful.
So I'd say that only adding a comment explaining "why" you did something is justified, imo.
I can see that. A case can also be made for library code too. For exceptional cases, I would still try to capture the comments in util methods wrapped in class describing their purpose. With any luck, those methods would read like steps in a recipe. If that wasn't feasible, I wold assess adding it to an ADR or some formal place where I can capture, in greater detail, the context and solution.
Love it! I wish you were on my team.
I would add that comments are a code smell, and you can easily work the comment into a well named function, class, or variable.
Agree. However, there's one exception. Sometimes we do stuff because of something else ,like DB limitation, 3rd party config, etc. Adding a comment to explain "WHY" you did something is helpful.
So I'd say that only adding a comment explaining "why" you did something is justified, imo.
I can see that. A case can also be made for library code too. For exceptional cases, I would still try to capture the comments in util methods wrapped in class describing their purpose. With any luck, those methods would read like steps in a recipe. If that wasn't feasible, I wold assess adding it to an ADR or some formal place where I can capture, in greater detail, the context and solution.