True full stack in #fintech. Analysis, solutionizing, developing and delivering.
Mostly working in dotnet and javascript, with a passion for process optimising!
For the sake of constructive debate, I always advocate for commenting - Where sensible.
If you have worked with a large (as in Enterprise) code base of substantial complexity, coming back to fix a bug in some 10 year old code is a lot easier if the methods have basic descriptions in the summary explaining usage. Especially so if there are override methods in play. You _could _argue that if a method isn't obvious and you are following the SOLID principles you wouldn't get this issue, but that's a debate for another time.
Of course, There are _many _scenarios where I would agree fully with you. We have fairly trivial code in some places which comments would be almost useless. (i.e a method named "GetAgeFromDate").
With a super mature product which has seen many developers come and go, all with their own coding style (Even if we do have "guidelines"!), I have had comments save me entire days of debugging.
I think it's a case of being sensible and knowing when is a good time to add comments and when isn't.
Great input, thanks Rich. I completely agree with all the above.
I tend to work on the rule of thumb that any public properties/method signatures should have a brief summary of intent. However the contents of the method itself should follow the clean code guidelines more strictly.
I think the important thing is just being flexible and treating each scenario differently. As you mention, a method called GetAgeFromDate doesn't really need any commented explanation.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
For the sake of constructive debate, I always advocate for commenting - Where sensible.
If you have worked with a large (as in Enterprise) code base of substantial complexity, coming back to fix a bug in some 10 year old code is a lot easier if the methods have basic descriptions in the summary explaining usage. Especially so if there are override methods in play. You _could _argue that if a method isn't obvious and you are following the SOLID principles you wouldn't get this issue, but that's a debate for another time.
Of course, There are _many _scenarios where I would agree fully with you. We have fairly trivial code in some places which comments would be almost useless. (i.e a method named "GetAgeFromDate").
With a super mature product which has seen many developers come and go, all with their own coding style (Even if we do have "guidelines"!), I have had comments save me entire days of debugging.
I think it's a case of being sensible and knowing when is a good time to add comments and when isn't.
Just my 2c
Great input, thanks Rich. I completely agree with all the above.
I tend to work on the rule of thumb that any public properties/method signatures should have a brief summary of intent. However the contents of the method itself should follow the clean code guidelines more strictly.
I think the important thing is just being flexible and treating each scenario differently. As you mention, a method called GetAgeFromDate doesn't really need any commented explanation.