views:

94

answers:

5

Depending on the feedback I get, I might raise this "standard" with my colleagues. This might become a custom StyleCop rule. is there one written already?

So, Stylecop already dictates this for summary, param, and return documentation tags.

Do you think it makes sense to demand the same from comments?

On related note: if a comment is already long, then should it be written as a proper sentence?

For example (perhaps I tried too hard to illustrate a bad comment):

//if exception quit

vs.

// If an exception occurred, then quit.

If figured - most of the time, if one bothers to write a comment, then it might as well be informative. Consider these two samples:

//if exception quit
if (exc != null)
{
    Application.Exit(-1);
}

and

// If an exception occurred, then quit.
if (exc != null)
{
    Application.Exit(-1);
}

Arguably, one does not need a comment at all, but since one is provided, I would think that the second one is better.

Please back up your opinion. Do you have a good reference for the art of commenting, particularly if it relates to .Net?

Thanks.

+2  A: 

Taking the time to write clear, readable, understandable comments is never wasted. How many times have I re-read my own comments at some later date only to struggle to understand them. People who write sloppy or badly formated comments often appy the same traits to their code.

Ricibob
+5  A: 

If code needs a comment, then it should be well formed, because IMO there's probably a (non-trivial) concept that needs explaining.

Trivial comments such as in your examples should be avoided. They add nothing but noise.

spender
+1 for the tip about avoiding trivial comments
SDX2000
+3  A: 

I often write comments that are simply meant to help me find sections of code. (I also use regions for this.) For example:

// SERVER

Because the IDE colorizes comments, it makes it handy at times to have short comments like this to assist in mentally blocking things into segments. I usually do this for only a dozen or so lines of code. If it's longer, then a #region seems better.

I also often write notes in my comments, sometimes as a reference for myself like this:

// NOTE: -273.15 is absolute zero in °C, used for a MinValue below

It's not a grammatically beautiful or complete sentence, but it makes sense.

Where I tend to use more complete, structured sentences is in the summary of my methods, like this:

/// <summary>
/// Populates the properties of a Sensor object based on
/// the XML components of its data file.
/// </summary>

Those I feel are more likely to be read by someone else and it helps to have verbosity and clean formatting.

JYelton
+1 For the summary bit, that's quite nice. Some of my colleagues setup Resharper to strip out all "traditional" comments.
Chris O
You type ºs in your code?
igul222
Sure! It's just alt+176. I deal with that symbol a *lot* in my work! :)
JYelton
NOTE: -273.15 is absolute zero in °C, used for a MinValue below. - this is almost a proper sentence, just slap a "Please" in front of it. That is what I was trying t get at. Yes, I can see how "// Server", or "// Constructors" are useful. I guess the question is again - if a comment is already long, then should it be a proper sentence?
Hamish Grubijan
I think my official answer would be "no," because there's no true reason other than if you are more comfortable with proper English (or other) language notes. No grammar police are going to check the comments. The only reason it might matter is if you are in a team development environment and your colleagues insist that you improve the readability of your comments. :)
JYelton
Yes, I am in a team environment and I would like to see better comments :)
Hamish Grubijan
Then you have your answer! :)
JYelton
+1  A: 

if you commenting methods in visual studio you should consider using the summary and params at the top of the method. This way you have detail about the method during code complete. Here is an example

    /// <summary>
    /// you summary here
    /// </summary>
    /// <param name="param1">Describe parameter usage</param>
    /// <param name="param2">Describe parameter usage</param>
John Hartsock
Quoting the OP "So, Stylecop already dictates this for summary, param, and return documentation tags"...
spender
+3  A: 

I've found that when I try to be brief with comments (i.e. incomplete sentences, fragments), I often leave out key assumptions or words that would actually clarify meaning. I'm having a hard time of coming up with a concrete example at the moment, sorry.

In general, though, forcing yourself to write complete, proper sentences also forces you to think more about what you're really trying to say with the comment. I've often caught myself rethinking what I really want to include in a comment by writing it out in full.

There's no good reason to sacrifice clarity at the altar of brevity. Someone will need to understand the code in the future. The comments are for them, so make them easy to grok.

Chris Schmich