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.
A small one that is often overlooked: comments should be complete sentences. (Throughout, “comment” includes docstrings and any other English you write about your code.) Start comments with a capital, have a subject and a verb, and end them with a period.
Comments should be complete sentences. If a comment is a phrase or sentence, its first word should be capitalized, unless it is an identifier that begins with a lower case letter (never alter the case of identifiers!).
Everything from the // to the end of the line is a comment. To mark an entire region as a comment, use /* to start the comment and */ to end the comment. * This is a block comment.
Periods are for the end of a sentence. Comments are not necessarily full sentences. Comments, in general, should be sentences.
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.
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With