After many years of coding, trying various programming styles, weeding out unreadable or impractical stuff, I still can't figure out one thing: what is the best way to single-line-comment multiple lines of indented code.


//    if (object->looks_suspicious())
//        guard->full_body_scan(object);


    // if (object->looks_suspicious())
    //     guard->full_body_scan(object);


    // if (object->looks_suspicious())
        // guard->full_body_scan(object);

Please, don't suggest multiline commenting, because sometimes you want to leave that possibility for bigger blocks, which may include smaller pieces of comments.


Since you do this for testing purposes, you normally want to have that stand out as much as possible, so you don't overlook removing the comments or the code later. Comment markers on the left margin are more visible.

  • Yes, except it's not always for testing purposes. Sometimes you leave a few commented lines of code as a message, e.g. "this could have been here" or "might come back one day". Customer's requirements, you know, they come in an arbitrary and illogocal manner. In these cases (longer-term commenting) I go for 2 or 3. – mojuba May 11 '11 at 15:01
  • 6
    "Might come back one day" is what source control is for. – whatsisname May 11 '11 at 15:05
  • 1
    @whatsisname: look through 1500 updates to see which one to revert back? – mojuba May 11 '11 at 15:09
  • @mojuba: wouldn't you realistically have some other criteria to apply when searching rather than looking through the entire commit history? And if you're looking to revert that 1-in-1500 change and finding the particular commit is too much trouble, wouldn't it be simpler to reimplement given the current conditions? If it'll take three hours to find / revalidate (nothing is ever exactly the same as before) / retest or one hour to reimplement & test, reimplementation seems to be the better choice. ('three hours' is pulled outta my backside and has no particular significance) – DaveE May 11 '11 at 16:29

This is how Visual Studio does it when you click the comment selection button:

    //private void Parse()
    //    while (_InputQueue.Count > 0)
    //    {
    //        switch (ParseState)
    //        {
    //            case AvailableStates.Begin:
    //            case AvailableStates.Found_ETX:
    //                byte FirstByte = _InputQueue.Dequeue();
    //                if (FirstByte == STX)
    //                {
    //                    ParseState = AvailableStates.Found_STX;
    //                }
    //                break;

I think it works well and looks nice. Of course the syntax highlighting accounts for probably half of the 'quality'


Whatever you like. You are not supposed to leave things like that for more than the time of fixing some issue, right? So it will disappear in a few minutes.

If instead you are actually using code like that for longer times, that is a different issue. Just remove the blocks you don't need and use version control to be sure you will be able to find them again in case you need them in a month.

  • Yes but: like I said elsewhere in this thread, longer-term commenting of code is not uncommon, and version control may not always be practical for this purpose if you have hundreds or thousands of updates already. – mojuba May 11 '11 at 15:11

When I comment out code I always put the comment before any indentation since, as @David Thornley says, it stands out better when browsing through the code. Also, as I use vim, it's easy to insert/delete the comments in visual block mode without messing up any indentation.


There is no objective "best" was - every style is valid and there might be personal preferences for each of these three styles.

Personally, I always use the first style (having the // starting on the first column) since that's the default settings for most IDEs I know of and it simply looks good.


As I see it, the importance of source code formatting is secure and fast navigation. That's why line comments should safely been skipped, of course without reading them.

As to distinguish comments (//) and documentation (///) from so-called "commented-out blocks" in committed source code, I decided to use two special line comment styles. This was several years ago and I do not regret it.

1) //<< a block that is part of a "transactional" deletion:

//<< /// what something does...
//<< void something_obsolet()
//<< {
//<<     some_stuff();
//<< }

2) //<? marks a deletion whose effect I'm currently checking in the IDE:

if (condition) {
//<? } else {
//<?             do_something_else();

Of course, I use version control to managing variants. But (1) when deleting different corresponding parts, I change between compiling and searching to get rid of all of its remains. Whenever I find comments of this style in committed code, I delete it without even thinking about it. Even if in very rare cases, I use a special comment style (2) for testing particular deletions within an IDE, because I cannot predict the next phone ring, this style is my most short-lived one.

Thus the question about indentation becomes secondary, but as I observed putting the comment-out marks leftmost, right at the beginning of the line, seems to work best...


Eclipse does it the way you have displayed it on example 1 and personally I find this way much more readable than the others.

Not the answer you're looking for? Browse other questions tagged or ask your own question.