// Return result
return result;

Why?

This brings back back memories of “over documented” work.

I don’t mind documentation, I don’t mind a lot of it either, but when it gets to the point of this example then it becomes pointless.

//+1
1++

When you feel you need to document but you're too lazy to doc the important parts.

LOL~
That’s how u comment a self explain code xD (LOL...)

That is me. I explain why I did this. I will put my own words in to every single line of the code. This helps me to comprehend 100 and 10 percents. And be able to memorise the code. This is just me.

Wow I would have never guessed! Such commenting, much useful >_>

// comment rant if this is serious
rant.comment( "is this serious?" );

//WTF
return Me.WTF()

I rarely add comments.

Instead, I try to write the code in a fluent way where the method calls almost read like English sentences.

When I'm doubt about readability, I ask someone from Design to glance at the backend PR, and tell me what they think it does.

In some cases you need to write lower level stuff, where performance requirements make you pick an uglier one-pass optimized loop over prettier subsequent map/reduce/filter calls.

But even then, I try to just keep it under 20 lines per method, and rather add a fat paragraph in a docblock at the top than explain every single line separately, because a future developer wants to know what that unavoidably mysterious black-box method does instead of reading some kind of parallel pseudocode.

@bittersweet
Comments should not duplicate information but supply information the code can not. I too try to make my code well readable by naming and structure and then i ask myself "how would i explain this to a colleague" and the things i would tell that are not already in the code in a clear way, that's comment material.