Do all the things like ++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatarSign Up
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple APILearn More
devdiddydog101283dThe level of stupidity here is impressive.
Wonder what he thinks why comments have been implemented
sariel612583dGive the dumbass what he wants, as long as he puts it in writing.
Then upload the email tob the repo, and just reference the email for every single commit comment.
When something goes terribly wrong he's either going to be fired or fucked so hard he'll beg forgiveness.
Lensflare472483d1. Why does the manager read and has something to say about PRs?
2. Depending on the kind of comments, he might be right.
Demolishun1840983dIt was this comment wasn't it:
// my manager (Bob Hopeless) made me implement this stupid feature
jiraTicket145082dSince it's a manager reading code I assume it's a bit of a Dilbert boss.
But there is a school of reducing the amount of comments as much as possible arguing that'll help code clarity. And if someone needs a deeper explanation they can dig through git history
fiftyhz41482dBut the only self documenting code that is perfectly clear without any comments is my own! … OK, just kidding. I’ve heard this no-comment school of thought time and time again. Usually the person evangelizing the idea writes the least amount of code and does even less prod support.
Lensflare472482d@fiftyhz In my current company, all colleagues from all teams that work on iOS and Android apps do this.
It‘s not some single dev weirdo that tries to evangelize it. It is the standard.
It may have something to do with the fact that we are using properly typed languages which make it easier to write self documenting code, but that‘s just a guess.
The point is: It‘s not as obscure or academic as some of you think.
And needless to say: It works!
cprn125381dThere are why-comments and what-comments.
What-comments make no sense. You can see what the code does - it's right there in front of your eyes - and if you can't then it's a mess, abstract it and name the method accordingly.
Why-comments are invaluable. Two years from now nobody including the author will know why that piece of code requires black voodoo shift operators.
jiraTicket145081d@Lensflare I agree. I think a code comment should be an unusual exception for most internal repos (of course not counting public apis where each public method is commented or similar) and I do think it enforces code clarity.
Some exceptions where I would allow comments is when the code is seemingly illogical due to a business decision making
jiraTicket145072d@Lensflare Excellent explanation.
* a dumb HOW comment would be something like unnecessarily describing how a for loop works when it's clearly visible in the subsequent code
* an acceptable WHY comment would be if an external factor is in play that you cannot understand based off reading code alone. Like if you have a value that mustn't be used for example "this value is set in our legacy CMS but it's incorrect and the CMS can't be changed so we must modify the value on our end"
alturnativ18870d++ @lensflare and @cprn, and better yet are the "why NOT" comments - saves others wasting time trying to do something a different way only to eventually realise why the existing implementation is in place.
I'm a fan of extracting things into methods with very descriptive names to make code as easy to read as possible. E.g.