The comment must be helpful. If it does not explain anything about the source code, it must be removed. It includes comments which repeat what the code does:
// Adding three to the variable n.
this.n = this.n + 3;
or some "false comments" which are in the wrong place:
// 2011-06-22 by Joe: replaced the SQL query by the new one.
Now, how often do we need to put comments? Is it one comment for each ten lines of code? One comment for every forty lines? Well, it depends. Complicated code may have lots of comments. For example it is the case when it is required to write a piece of code optimized for performance more than for readability. Easy to understand code on the other hand may do not have any comment at all (with a few exceptions, like the comments for every method or property or field).
//due to lack of confidence with web programming leaving this note in for now comment useful?
Well, it would be if it were more detailed. Reading this comment, we may think that the following code may not match the best practices, or not be very correct, or may even do something different from it was expected to do, unless in some circumstances. But we don't know anything precisely, so we must explore the code to guess (while comments are intended also to avoid forcing the reader to explore the code).
It would be helpful on the other hand to write comments like:
// I'm pretty sure that in web programming, we must keep the following data in
// sessions or in database, but writing specific database queries would be long,
// and I can't find how to use sessions, so I'll keep it this way.
// I'm unsure that the JSON serialization must be done like this. Probably there
// is a method in .NET Framework to do it in one line, but I can't find it.
// TODO: search MSDN for a correct way to serialize to JSON in .NET.
I always suggest adding a TODO in those cases. When you write code, you are expected to know how to write it the correct way. But you may not have time to learn everything you need before writing it. By adding a TODO:
- You notify the reader that you just postponed the search, but are willing to learn new things,
- You can easily find TODO comments later (Visual Studio even shows you a list of TODO automatically from the comments),
- You highlight that the code is not perfect, and must be modified before RTM.