Re: [boost] Re: Suggested coding guidelines

From: Greg Chicares (chicares_at_[hidden])
Date: 2001-07-07 10:52:58

Larry Evans wrote:
> 
> What about:
> 
>     void foo
>       ( T1 p1
>       ,  T2 p2
>       ...
>       ,  TN pN
>       )
>     {
>      }

Wouldn't you prefer to vertically align the other parameter names
with T1, and the '}' with '{', by deleting one space before each?

That said, I see good reason to like this style.

Motivating example

  #include <iostream>
  int main()
  {
    char* foo[] =
      {
      "one",
      "two" // there was some comment here
      "three" // then I added this
      };
    std::cout << foo[1];
  }

I did something like this once, and spent two hours looking for the
problem in all the wrong places.

Discussion

When you add an extra function parameter, it's harder to forget to add a
comma if you follow Larry's style. That's why some people used to write

  enum
    {
    a = 1,
    b = 2,
    // Preceding comma: ready to add a new enumerator-definition here.
    // Otherwise, to add anything we'd have to change the preceding line.
    };

although that's nonstandard now and never worked for function prototypes.
This style conforms to the standard and secures that advantage.

Since the (simplified) syntax of a function prototype is

  return-type function-name([parm0] [,parm1] [,parm2]...);

the comma introduces the following argument rather than ending the
preceding argument. Line breaks might be inserted this way

  return-type function-name
    ([arg0] [,
    arg1]   [,
    arg2]
    ...
    );

or this way

  return-type function-name
    ([arg0]
    [,arg1]
    [,arg2]
    ...
    );

The second seems clearer to me, especially when there are comments
between closing ']' and the next opening '['. Consider:

  void foo
    (int parm0, // parm0 is an int...and another parm follows...
    int parm1,  // ...the parm that followed turns out to be parm1
    int parm2   // no comma after parm2 means there is no parm3
    //
    // Want to delete parm2? Don't forget to delete the comma in
    // the middle of the line with parm1.
    //
    // Want to add a new parm3? You'd better remember to insert a
    // comma between parm2 and its comment.
    );

versus

  void bar
    (int parm0 // parm0 is an int
    ,int parm1 // parm1 is an int
    ,int parm2 // parm2 is an int
    // To add another parm, dup last line and edit only the new line.
    // To delete parm2, just delete the line it's on.
    );

The compiler can help if you forget the commas in foo() above, but there
are parallel cases where it can't detect a problem, like the motivating
example above, which is syntactically valid. The leading-comma style
would have made it harder to make that mistake. Kind of like writing
the constant on the left in equality comparisons
  if(42 = some_integer)
because I remember that equality is spelled '==' only 99% of the time.

This style is not common contemporary practice, but is there any other
reason to dislike it? (I'm not saying is should be required, just
not forbidden.)