Are there standard formats for comments within code?

Question

I'm wondering if people have a standard format for comments in their code. Not things like xml comments for a method or class but rather comments within a method.

---

See also:

Is there a standard (like phpdoc or python’s docstring) for commenting C# code?

Answer 1

// I usually write comments like this

Where I work it is required to use standard xml comment style for most of the declarations (classes, methods, some properties) (we use C#).

Sometimes you can see header/footer comments in use.

/****************************************************/
// Filename: Customer.cpp
// Created: John Doe
// Change history:
// 18.12.2008 / John Doe
// 14.01.2009 / Sara Smith
/****************************************************/

/* Here goes a lot of stuff */

/****************************************************/
// EOF: Customer.cpp
/****************************************************/

Something like this was used at one of my old places of work. In my opinion too much of unnecessary stuff. Change history is nicely seen these days through a version control system.

In many good software shops there are internal guidelines as to when and how to write comments. Documents are typically referred to as "Source code style policy" or something. It is very important to adhere to one common style in commenting the code.

Of course this commenting hype shouldn't go too far as to comment every little piece of code, especially the obvious ones.

/// <summary>
///     Handles the standard PageLoad event
/// </summary>
/// <param name="sender">
///    Event sender
/// </param>
/// <param name="e">
///    Event arguments
/// </param>
public void Page_Load (object sender, EventArgs e)
{
    // Do something here
}

This one is a good example of over-obsession with commenting. Something like this adds exactly zero information but only adds noise to the source file. And we have to do it at work as required.

My personal opinion is add comments when you have something to say or explain, not just for the sake of commenting everything.

Answer 2

' I usually write comments like this

Answer 3

/* I will sometimes write
comments like this */

Answer 4

(* Modula-2 comments go like this *)

Answer 5

Comment on the line above the code (block) that does what you're describing

// This is a comment.
Some code goes here

Avoid doing stuff like

// ----------------
// IMPORTANT COMMENT
// ----------------

And I avoid using the

/* comment */

And perhaps most importantly, clean up comments! A comment that describes non-existent functionality is worse than no comment at all.

Answer 6

/*
 * Brief summary of what's going on.
 */
int code_that_goes_on(int c)
{
     /* and then if I have to remark on something inside... */
     return 0;
}

99% of compilers will support // comments, which is awesome, but that 1% still exists, and it's not too difficult to make life livable for them.

EDIT: The Delphi comment is a bit obtuse, but does point out a real deficiency. I intend this to be a C-specific answer.

Answer 7

-- I usually write comments like this

in SQL

Answer 8

<!--How about comments like this!?-->

Answer 9

/**
 * block comments to document a method for javadoc go like this
 * @param
 * @return
 * @exception BTKException
 * @see BTK
 */

Answer 10

There can be religious wars on this subject.

What I try to do, that doesn't cause too much warfare, is

 // explain the purpose of the following statement in functional terms
... some statement ...

The idea is, if I run the code through a program that deletes everything except the comments, what is left is pretty good pseudocode.

Something that's useful as a way to comment out code that you think you might need again is:

 /*
 ... some code ...
/**/

then modify the first line - either delete it, or change it to /**/

 /**/
... some code ...
/**/

Answer 11

I can't believe we missed the REM keyword.

Though to be fair, it's for REMARK not COMMENT.

Answer 12

# ----------------------------------
# BIG IMPORTANT COMMENTS IN PERL/SH
# ----------------------------------

Answer 13

//Cheap Debugger

//Response.Write(MySQLStringBecauseINeedToKnowWhatsBroken);

Answer 14

You should really consider a couple things to make good comments beyond formatting.

1. Do not simply restate what the code is doing. For example,

 // Start the services
 StartServices();

is a frigging terrible comment!

1. Describe why. Why is the code doing what it's doing? What's the business assumption or algorithm step?

2. Format your comments for maximum readability. Tab them properly, leave spaces where necessary, etc.

3. If someone has already started commenting in a standard way, don't break that standard.

4. Check this article on MSDN about writing effective comments: http://msdn.microsoft.com/en-us/library/aa164797.aspx

Answer 15

//For one line, I write them like this

/*
For multiple lines of text
I write them like this
*/

/*
for(multiple lines of code){
  I.WriteComents(With("//"));
  Reason==If(I.Remove('The top begin-quote mark') then
    I.Worry.Not('About removing the close-quote mark');
//*/

Answer 16

If you are paranoid and don't use or trust source control, you might do this

// Initials-YYMMDD-fixNo-Start
dosomething();
// Initials-YYMMDD-fixNo-Finish

It makes a bloody big mess, but it gives you some way to rollback changes.

But I'd suggest using source control

Answer 17

The problem with comments within a method (rather than in an interface), is that they are actually not meant to be seen by anyone except for people maintaining that method. Therefore, there is no real need for a standard for the comments. They don't get published anywhere, they're not publicly visible, callers will generally never see them.

In general, comments inside code should follow four rules: 1) They should not state the obvious 2) They should be consistent with what they describe 3) It should be clear what they describe (e.g., which line, block). 4) They should be readable by any future maintainer.

That being said, there is often a tendency to place information that is important to the callers as an internal comment. For example: "OOPS, This doesn't handle negative numbers". Whenever you see an internal comment, reconsider whether the header documentation should be updated, or use a tool that "pushes" the comments to the awareness of function callers (I have a tool like that for Java).

Answer 18

I like to do things like this:

/************
*  Comment  *
************/

That way i have to waste time reformatting the entire block any time I add/remove text

Answer 19

I don't think there is a standard for what you are asking. And I don't see how it would add any benefit from /// comments on the method itself.

For creating documentation from your C# classes take a look at Sandcastle.

Answer 20

Comments standards are most useful when the comment will be parsed by an external tool (usualy, a document generator, like javadoc).

In this case, the external tool will state the standards.

For other cases, see How do you like your comments? (Best Practices)

Answer 21

In C/C++/C#/Java, when I have a comment explaining a block of code:

// comment
code;
more_code;

when a comment is explaining a single line:

code; // comment

I usually use // for single sentence comments and /* ... */ comments for multi-sentence comments.

Answer 22

One comment style in C++/Java etc is this:

// Use // for all normal comments...
// and use multiline comments to comment out blocks of code while debugging:
/*
for(int i = 0; i < n; ++i) {
    // If we only use // style comments in here,
    // no comment here will mess up the block comment.
}
*/

I think it is an interesting point, even if it's not that incredibly useful.

Answer 23

My code is self-documenting. I need no comments.

Answer 24

There are packages that will help write and format documentation. They require some specific changes so they can identify classes of comments.

such as doxygen:

http://www.stack.nl/~dimitri/doxygen/docblocks.html

/*! \brief Brief description.
 *         Brief description continued.
 *
 *  Detailed description starts here.
 */

Answer 25

I'm surprised that not more people recommended doxygen. It is a good way of documenting code, with the side effect that it can automagically generate html + pdf API documentation at the end of the day.