Are comments really universally agreed to be evil in large .NET codebases?

I'm working as a tester on a project for a small finance company. While management sometimes makes "interesting" decisions, the team I'm working with seems competent enough. Since I'm usually on the developer part of the equation (this project being a temporary job) I've taken an interest in the code of the project. Today I remarked that the code seemed to be pretty light on comments (which isn't an exaggeration; there aren't any) and was immediately told that it's intentional and that "source code comments are your worst enemy in large code bases."

Being hired as a lowly tester and not having any real experience developing large, enterprisey systems, I didn't see fit开发者_如何转开发 to question this sentiment but I'm still wondering if this really is a universally accepted fact?

Of course code should be written in a clear, self-explanatory manner as far as possible, reducing or eliminating the need to comment individual code snippets, but this project intentionally doesn't seem to use any comments at all, not even xmldoc comments for methods and/or classes, which just seems horribly wrong to me. Is this really universally agreed on as best practices for large projects?

Comments do tend to get out of date, and an incorrect comment is indeed worse than no comment. Likewise, xml comments if enforced by mandate tend to be so minimal (just to make the compiler happy) as to add zero value.

However; comment when comment is due is fine IMO. I am very light on my comments, but when I add a comment it is important - it might explain the reason for a particular design choice; some non-obvious facet of the logic that needs to be understood; or some gnarly threading concerns that the casual reader must be aware of. It might cross-reference a business rule, an error-ticket/case-number, or cite some external reference for more information on a topic.

So indeed, I agree with you that no comments (by rule) is stupid. But too many comments is stupid too (IMO). I want my focus brought to stuff that matters, and I can't do that if the code is drowning in green.

In my corporation we have heard the line "code is self-documenting" often enough that we joke about it. There is a good article in VisualStudio Magazine entitled To Comment or Not to Comment that may be worth a read.
Personally I feel comments are necessary and should be maintained along with project documentation. The problem is that when there is no template or general understand of what "comments" mean it is nearly impossible to maintain consistency between the code and the comments so they become useless and programmers tend to ignore them.

That's a pretty bizarre sentiment.

The general consensus seems to be that comments are important, because they explain the purpose of the code, the why. In contrast, the code itself is the how. (Comments that explain the how would be redundant.)

Comments are in some cases important for the what: often it's needed to do something kludgey, and a comment can explain what's going on.

xmldocs are very important for explaining the contract of a method. Some languages (e.g. Eiffel) actually have syntax for specifying contracts, but in most languages, this must go in comments. Even considering the ideal of self-documenting code, you can't really explain a method's contract in the name of the method!

Comments can also mark to-do items, point out things to be fixed, etc.

There is certainly some merit to the view that code should be self documenting.

Also it's very easy to drown what your actual code does in all the xml-documentation. Look through the java or .net base libraries for some truly scary examples of this.

That being said though, if you get handed a dll of internal code with no documentation and no access to the sourcecode you may really struggle so - as you say - xmldocs have a clear benefit, at least when you dont have the sourcecode easily available.

Another place where you should certainly have comments is when you do something that is strange or unexpected. An empty catch block for instance would merit a comment on why this is not a bug.