You could argue that the code is already doing the job of documentation. Would you say that you get the idea faster by reading something camelCase like userAge than a well-versed English sentence The age of the user?
Yes, indeed. A 30 line function with 15 lines of logic + 15 lines of comments will take up more cognitive load compared to the one with 0-2 lines of comments and good naming/structure.
I don't encourage this type of comments, but I don't see how it is damaging you either.
It's clutter and noise, IMO.
Would you remove this type of comment if you find it in a program that you're working with?
In a collaborative scenario? It's a point of discussion with the one who committed the snippet, that's for sure.
Yes, indeed. A 30 line function with 15 lines of logic + 15 lines of comments will take up more cognitive load compared to the one with 0-2 lines of comments and good naming/structure.
Hmmm I think that I get your point now. When looking at a function for documentation I always read the comment and skip the code (unless debugging/reviewing it, in which the comments are helpful to understand the intended behavior), so I don't feel this cognitive load (this is just me though).
In a collaborative scenario? It's a point of discussion with the one who committed the snippet, that's for sure.
I'm not too sure if this is worth taking even 3 minutes from someone else's times to discuss whenever the comment was needed or not. You must be really feeling the clutter/noise to consider it a point of discussion.
Perhaps if one member of my team is writing this type of comments and he/she had done it several times, I'd take 5-10 minutes to speak with that person about it (I still wouldn't ask the person to remove the comments..).
I'm not too sure if this is worth taking even 3 minutes from someone else's times to discuss whenever the comment was needed or not.
Setting up standards is an important point for a development team. If the guy that writes comments like these have a reason for doing so, he should discuss it with the team for standardization.
I totally agree with John, I think comments add much clutter to code and you have to use them carefully. Writing self explanatory code is not an easy task so sometimes comments can cover it.
But eventually it is up to the team culture. If your team likes to comment so go ahead and just do it
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.
Yes, indeed. A 30 line function with 15 lines of logic + 15 lines of comments will take up more cognitive load compared to the one with 0-2 lines of comments and good naming/structure.
It's clutter and noise, IMO.
In a collaborative scenario? It's a point of discussion with the one who committed the snippet, that's for sure.
Hmmm I think that I get your point now. When looking at a function for documentation I always read the comment and skip the code (unless debugging/reviewing it, in which the comments are helpful to understand the intended behavior), so I don't feel this cognitive load (this is just me though).
I'm not too sure if this is worth taking even 3 minutes from someone else's times to discuss whenever the comment was needed or not. You must be really feeling the clutter/noise to consider it a point of discussion.
Perhaps if one member of my team is writing this type of comments and he/she had done it several times, I'd take 5-10 minutes to speak with that person about it (I still wouldn't ask the person to remove the comments..).
Setting up standards is an important point for a development team. If the guy that writes comments like these have a reason for doing so, he should discuss it with the team for standardization.
I agree that setting up standards is very important, thanks for your thoughts.
I totally agree with John, I think comments add much clutter to code and you have to use them carefully. Writing self explanatory code is not an easy task so sometimes comments can cover it.
But eventually it is up to the team culture. If your team likes to comment so go ahead and just do it