Coding since 11yo, that makes it over 30 years now ~~~
Have a PhD in Comp Sci ~~~
Love to go on bike tours ~~~
I try to stay as generalist as I can in this crazy wide place coding is at now.
Totally agree!
The senior devs I've worked with tend to end up removing more comments than they add.
Excessive comments tend to be removed during peer review.
Comments are essential where it's hard to get the intention of the code by reading it, which is sometimes unavoidable but should be the exception not the rule.
Clear code shouldn't need comments. Tricky code does. No use filling your codebase with tricky code.
Yeah. Comments should be removed in peer review. They are just to give understanding of something tricky. Complex code should be avoided if it's not needed.
Aging Java back-end guy. Ironically although I got my github thinking I'd fill it with nifty stuff I'd do in Java on my own time, I've ended up sticking a load of JavaScript on it instead!
Comment to document the why of the code, not the what. What it's doing should be immediately apparent, but why the client wants it to do that may be important for future maintainers. The last thing you want is for some new dev to rip out something that makes little sense, only to find themselves hauled into the CTO's office to explain why they've gone against the client's wishes & be embarrassingly made to restore it in an emergency release.
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.
Totally agree!
The senior devs I've worked with tend to end up removing more comments than they add.
Excessive comments tend to be removed during peer review.
Comments are essential where it's hard to get the intention of the code by reading it, which is sometimes unavoidable but should be the exception not the rule.
Clear code shouldn't need comments. Tricky code does. No use filling your codebase with tricky code.
Yeah. Comments should be removed in peer review. They are just to give understanding of something tricky. Complex code should be avoided if it's not needed.
Comment to document the why of the code, not the what. What it's doing should be immediately apparent, but why the client wants it to do that may be important for future maintainers. The last thing you want is for some new dev to rip out something that makes little sense, only to find themselves hauled into the CTO's office to explain why they've gone against the client's wishes & be embarrassingly made to restore it in an emergency release.