Do all the things like ++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatarSign Up
Good on you for leaving, you stood up for what you believe in
Nicely done. So many twats as tech leads
In fairness, I have similar feelings about code comments. If you really need comments *within* code, then your code generally isn't clear enough.
But yes, there's no way I would have put it like that. That's a minor point in a code review, not something you storm over and scream and shout over. Good job with deciding to move on.
@AlmondSauce oh god not this bullshit again. There are so many things like business logic gotchas and legacy sugarcoating that just can’t be explained away by even the best architected code possible. Code can tell you the what’s and how’s but you need comments for why’s.
While I do agree with the sentiment code should be clear enough that it shouldn’t need comments. There are some things that can be expressed only with comments.
@grumpyoldaf Agreed, hence the use of the word "generally" in the above. Apologies if I wasn't clear.
The OPs line of "how can anyone else use my code if I don't comment or document it" however makes it sound like the code is unusable as-is in its entirety, which *would* be a worrying sign.
That said, even if that is the case, there's ways and means of dealing with it in a sensible way, and the tech lead here is undoubtedly a massive arse.
@grumpyoldaf right, and comments are also good if something has to be done in some place because something else is done in another. Because that's what will trip up the maintenance programmer 5 years later who doesn't know the whole codebase.
I remember an incident where I got a bug report, went through the code, and right at the point where the strange behaviour was, my predecessor had left a comment. It was because a totally different requirement kicked in, and the whole thing actually worked as specified.
Liser55k777dThe comments in my code was for the modules documentation like what you get when you import the modules, i.e if a person wants to use the module he would know what to pass as arguments.
And in-case of comments they were generally
#To-Dos, like what more I can add and what errors faced if something changes and all...I think it is necessary for better readability no matter how clear your code is!!
cprn3147dActually... The CS you used should comply with whatever they had before you came in and some developers prefer clean, easy to understand code over comments. My current employer doesn't even allow doc blocks because there were too many cases of coders making changes and not updating comments, hence, we got a separate team dealing with docs. It works better than I thought it would. 1st, there's less on coder's mind when he does his job. 2nd, they're good rubber duckies. While it can be a challenge to rewrite something to make it readable enough to really not need the "what" comments, it's usually doable. Sometimes fun, even.
Above said, I neither agree nor disagree with my company policy. I just say it's not that uncommon to follow "their ways".
I always just use the naming conventions that everyone else at the company does
Your Job Suck?
Take a quick quiz from Triplebyte to skip the job search hassles and jump to final interviews at hot tech firms
Get a Better Job