My manager doesn’t like code comments, want us to remove from PRs 🤦🏻‍♂️🤦🏻‍♂️

The level of stupidity here is impressive.

Wonder what he thinks why comments have been implemented

Give 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.

1. Why does the manager read and has something to say about PRs?

2. Depending on the kind of comments, he might be right.

It was this comment wasn't it:

// my manager (Bob Hopeless) made me implement this stupid feature

@sariel thing is most of the time things don't go wrong. People are usually successful even doing dumb shit. No one notices if it was only 10% as successful as it could have been, it's not there to see that it's not there. That's what makes this job so fucking painful.

Since 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

@jiraTicket the idea is to replace comments by better code that describes itself. Not just removing comments. Git history is not a substitute for clear code either.

But 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.

@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!

There 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.

@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

@Lensflare Fair enough

@cprn agree. And naturally, "why" comments are very rare because in most cases it‘s clear why the code is there.

This "school of no-comments" is about stopping the pandemic of "what" comments.

@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"

++ @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.

if (WeShouldDoThatThing())
{
DoThatThing();
}