I talk about source-code-comments, that explains what happens on the next lines of code, not Javadoc/Doxygen-comments (that comment on the interface).
Comments can make your intention for the code clearer, but on the other hand they could be redundant or even worse outdated (code was changed without changing comment).
There was a very similar question raised this morning, maybe it's of interest to you: Comments in source code
Add comments where you need them to explain to another why you did something, the code itself should show clearly enough what you did. When Adding comments detailing what the code is doing is when you run the risk of redundant or outdated comments confusing readers of your code.
If software is understandable without comment. You don't need it.
Comment are a way to increase clarity. But they need to focus on the information that can not be expressed by source like the "why".
Good quality comment is always a good thing. Try seeing some old code of yours without any comments and time how fast you can determine what's going on.
Of course, comments are never a replacement for good quality code.
Source code comments unless meant to be machine collected are not a good idea.
When you write source code you tend to write comments, explaining the logic or something. Now, over a time your source code tend to be changed by multiple people and you end up having either latest source code or latest comments, but neither in sync. Of course, IMHO.
MS did a study on comments.
They catagorized code into three;
Second catagory - average comments - had the most bugs.
Turns out code with zero comments is written by people who know exactly what they're doing.
Code with lots of comment is written by people who fully understand what they're doing and explain it.
Code with average comments is written by people who don't really understand what they're doing.
there were many similar questions, just browse the comments tag. why asking again?
It seems to me to be impossible to document why you do something if you do not say what you do first. what is especially important if you use a non-trivial algorithm. Of course you do need to explain why you use that specific algorithm (speed? accuracy? etc).
Even if the why is not important, the what can be. In my experience it is much faster to read 1 line of English comment than 20 lines of code, even if the code is very understandable.
Besides, if there is no comment explaining what a piece of code should do, how can you determine whether it is doing it correctly? Indeed you might have the problem of outdated comments, but then you can at least make sure that at one of them (comment or code) is incorrect (or both). W/o the comment, you have no clue to what your predecessor meant to do.
Where I currently work it is required that people comment every single method including the standard ones (like Page_Load) by copying the standard stuff from one file to another. To the chef it increases readability. To me it adds noise.
If you have nothing to say, don't comment it.
What would be the point of a useless commenting like this?
/// <summary>
/// Handles the standard PageLoad event
/// </summary>
/// <param name="sender">Event sender</param>
/// <param name="e">Event arguments</param>
protected void Page_Load(object sender, EventArgs e)
{
// .........
}