Monday July 27th

Friday July 24th

.NET Coding Guidelines - Commenting

Nice rant about developers who don't comment their code, I can sympathize.

8 comments

Commenting code is over rated, I much prefer well written code which is self explanatory. If a piece of code needs comments, it may also need a refactor.

I agree to an extent, I'd usually rather have well designed self-documenting code than awful code that's commented. But, especially with larger and more complex systems, it good to have documentation and comments too, so you can tell what the programmer was trying to do, and why. There's a limit to what you can infer from code alone, no matter how well designed it is.

That's a fair point. As with pretty much everything else, balance is key.

Commenting for the sake of commenting is poor, however, commenting on the intent is a MUST. Simple easy to read code should not need comments. However, code the is odd/complex or is a 'hack' MUST have comments so the next guy can understand the 'intent/why' of what the code does.

dwhittaker - I agree, for hacks it's handy to use "HACK" comment, same for "TODO", so they show up in the Visual Studio Task List.

After seeing a 200k LoC project we outsourced last year come back with 0 comments, I have to agree that it's better to be safe than sorry and require a certain level of commenting. In the end, that project literally got scraped, because even the people who wrote it were unable to maintain it a year later.

I'm sure you'd all agree, but method/property commenting for use with Intellisense is a must in my book.

isuttle - definitely, it makes life so much easier when methods have XML comments that show up in IntelliSense. This feature will soon be available for JavaScript too, in Visual Studio 2008.

Commenting on Stories is limited for now and will open up to those recommended by the community. Learn how
Loading DotNetKicks...
brought to you by the Kicks Network