views:

125

answers:

3

I'm looking for a rather arbitrary answer, so this might more be a discussion. I'm wondering what the best practise for commenting my C# code in visual studio is. Right now I'm using the triple /// to generate the xml and use sand castle to build a chm or html file. But my problem is that I use code comments for two reasons:

  1. When other developers are using my code they can read the documentation, both intellisence and the chm. or html file.
  2. But I also use commenting as reminders to myself. So I can remember my thoughts when I come back half a year later, to some complex methods.

How can both goals be accomplished without interfering with each other, and in the same time be a quick task, not taking a lot of coding time?

+7  A: 

The best advice I can give you is:

Don't comment bad code; rewrite it!

If methods are very complex, than most of the time you are doing something wrong (not always, but very often). Writing readable code is hard, but pays of, because writing good comments that you (or your colleges) will understand a year later is hard as well. Ways to make things clear is by breaking methods up in smaller well named methods and using very clear variable names.

A book that has helped me a lot in creating better code was Robert Martins Clean Code. If you haven't read it, please do. And let all the developers in your company read it.

Good luck.

Steven
Thanks for the answer. I think we all have the duelling problem that we get paid for our work, so we have to create good code and don't use too many hours writing it. Sometimes comments can be used as a quick and dirty fix for this. And I know this isn't best practise :)
DNRN
I agree with you. There is always a trade off between good quality and economics. I certainly write comments like "// TODO: Don't forget to refactor this" or "// HACK: fix later" myself :-) Of course it depends on the type of project, but I often find myself writing code that has to be maintained for many years (often by other people than me) and in that case it really pays in the long run when I take extra care in writing it. When writing a prototype I take much less care of course.
Steven
@DNRN: Speaking of economics, have you heard of the concept of "Technical Debt"? The idea is that if you put off the refactoring for a later date, you are really just acquiring technical debt that will have to be paid off in the future, with interest. The interest in this case is the overhead of remembering what the code does. Instead, I recommend a quality refactoring tool, such as ReSharper or CodeRush that makes the job of refactoring extremely efficient. By using a tool like that, you get the best of both worlds... refactor now without the extra time.
Brian Genisio
+4  A: 

Use /// comments to document your public and protected API. Use <remarks> to describe how your API should be used. The audience of these comments are other developers using your code.

Use // comments to comment your code whenever the code alone isn't adequate to fully understand what is going on. The audience of these comments are yourself perhaps three months out in the future or another developer going to maintain your code. You can use special comments like TODO or BUGBUG to flag codes you have to revisit.

Martin Liversage
I use TODO myself as a little reminder of something that have to be implemented later, and have found it really useful. I like the "scope view" where /// are for for public and protected API, used in intellisene. the <remarks> used as extra info in the documentation file. and // are only viewed in code when reviewing it at a later time.
DNRN
+1  A: 

I combine both commenting styles - /// for 'public' documentation on classes, methods, etc, and // on 'private' comments for myself or the coders that follow me to read.

Jonners
This is what I do as well.
mizipzor