Can I reformat your code?

[Robert Graham Merkel]

On Wed, 25 Jul 2001 22:57:09 Bill Gribble wrote:
> 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.
> 

That's quite true, but as you have pointed out, there are some conventions
that are pretty much universal.

> 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.
> 

Agreed.

> 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.
> 

The last variation is my strong preference here - not wasting too many
columns, and making it dead easy to determine which blocks goes where
in nested code (though how much of that is due to my own familiarity 
with the particular style is a relevant question).

> 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 ) {

Is complete parenthesization really necessary?

As mode of our arithmetic is performed by gnc_numerics anyway,
it's somewhat of a moot point.

> 
> 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.
> 
Definitely.


One more point - what about scheme code?

-- 
------------------------------------------------------------
Robert Merkel	                           rgmerk@mira.net

Go You Big Red Fire Engine
-- Unknown Audience Member at Adam Hills standup gig
------------------------------------------------------------