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.
Beautiful tips. What about if you have to explain the functionality in comments you still have refactoring left
Agree. If you have to explain the code, then it means there is still room for improvement.
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.
That's a great option as well. I use ADRs for outlining technical decisions and architectures that guide the whole software.