Can I reformat your code?

[Bill Gribble]

On Wed, Jul 25, 2001 at 07:32:44PM +1000, Robert Graham Merkel wrote:
> Yep.  IIRC we break from the GNU Coding Standard in a couple of other ways
> (GNU style puts opening braces at the end of lines), but we should probably
> document those exceptions.

I think it's important that we come to a mutually agreeable coding
standard and stick with it.  It's misleading to suggest that we
actually have a standard now, though.

I agree with your suggestions to Josh; 80 columns and 2-space indents
are pretty much universal in the code as it exists and will be part of
any mutually agreed standards.

While brace styles are difficult to agree on, I know, the biggest
divergence in the Gnucash code base is in data type and function
naming conventions.  That's the stuff I would really like to see
cleaned up.

Most new code has been doing data type and function naming the way I
like it (ignore brace style in this sample code):

  typedef struct {
    int foo;
  } GNCNewDataType;

  int 
  gnc_new_data_type_get_foo(GNCNewDataType * bar) {
    return bar->foo;
  }
  
To summarize the "rules":
  - new data type names are in FirstLetterCapitalizedMixedCase and start
    with GNC if they are visible in a public API
  - function names are all lower case, with words separated by "_".
  - all functions in the public API are preceded with "gnc_"
  - if a function would be a method of a particular class in an
    object-oriented language, the name of the class is the first part of 
    the function name.

A rule I personally follow that I know a lot of people don't:
  - even if a function is *not* a "method", include the name of the 
    "package" or module it's part of in the first part of the function name.

In my code, generally every function prototype in a single header file
will have a fairly long common prefix in their names. This is a useful
grouping construct for me. 
  
Conventions on file naming and "classes":

  - A data type GNCNewDataType, if non-trivial, should be defined in 
    gnc_new_data_type.h and gnc_new_data_type.c.  Normally, the 
    C "struct" declaration should be in gnc_new_data_type.c, so
    that all access to struct fields is through function calls.
  - If multiple .c files need access to the structure directly, 
    gnc_new_data_type_p.h  should define it.

Brace styles: As you can tell by the examples above, I write all my
code in the venerable 1TBS with 2-space indents. I'm willing to
change, but I like it like that.  1TBS is the "one true brace style":

  if(foo) {
    bar;
  }
  else {
   baz;
  }

My understanding of GNU style is that it's

  if(foo) 
    {
      bar;
    }
  else 
    {
      baz;
    }

which I strongly object to.  I also can't really stand anything that
has } else { in it, but neither can most people.  Most *normal*
people, that is :)

  if(foo)
  {
    bar;
  }
  else 
  { 
    baz;
  }

is much better and I can live with it if people hate 1TBS.

Parens and spacing: I like spaces around arithmetic operators,
complete parenthesization in math expressions, and no spaces padding
parens.  i.e.

  if((a * b) + (b * c)) {

not 
 
  if ( a*b+b*c ) {


Function prototype: function names in their definitions should start in 
the leftmost column.

int
foo(int bar, int baz) {

not 

int foo(int bar, int baz) {


C Macros considered harmful: C macros are code obfuscators.  If you
need extensive macros, you need to redesign your code, IMO.