Can I reformat your code?

[Robert Graham Merkel]

On Wed, 25 Jul 2001 18:01:08 Josh Sled wrote:
> On Wed, Jul 25, 2001 at 03:28:43PM +1000, Robert Graham Merkel wrote:
> 
> | While I generally don't worry too much about indenting styles,
> | really long lines are a pain to read if you've got a couple 
> | of emacs windows open side-by-side and thus can't open the 
> | window wider than about 80 chars.  
> 
> Well, this starts to make lines very ugly, especially given that
> identifiers
> [both sched-xaction and GTK] are tending toward being rather long...
> 
> 			xaccSchedXactionSetMumbleFoo( med_ident_arg0,
> 						      long_idententifier_arg1,
> 						      function( arg_0_0,
> 					 			arg_0_1 ) );
> ...isn't what I'd prefer to see.
> 
> But, I've seen multiple arguments [the "split-window" argument and the
> "printing" argument] that say that all efforts should be made to keep
> lines w/in 80 cols...
> 
> | The tab indent is not 
> | particularly a concern, but it is hard to keep to the 80-char
> | limit if you've got nested braces and a standard 8-character
> | indent.
> 
> The nested blocks add to the depth, but the best general rule I've seen
> is: If you're running into nesting problems with 8-char indents, you
> probably have too much nesting going on. [as well, instances of nested
> blocks generally indicate that some refactoring of the code in those
> blocks out should occur, but I digress].
> 
there's a fair bit of truth to that, but with long, descriptive 
function & variable names it only takes a couple of layers of nesting
to run into trouble.

> OTOH, I've seen mostly 2-char indents in src/*... if this is the GnuCash
> standard, then `ident`-away [but see below :)].
> 
> | I'd like to run your C files through indent to 
> | convert to use the above conventions, to fix the above issues
> | and to keep them in line with the rest of the code.
> 
> What you'd like to do is fine with me.
> 
> I'd like this to occur when I'm not planning on touching the code, and
> after
> my present changes are committed [hopefully tomorrow night] to minimize
> merge conflicts.  Maybe we can coordinate on IRC for sometime this
> weekend?
> 
That sounds good.

> 
> Is there a GNUCash coding standards doc [other than 'HACKING'] that
> addresses this?  I think reffing the GNU Coding Standard is fine, so
> long as these two issues [indent width [2/4/8] and a line-length limit]
> are addressed.
> 
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.

> It was my mistake to prefix these new engine functions with 'xacc', but I
> was following the "similar-to-existing files" principle and somehow
> missed
> the "gnc_"-prefix-on-new-stuff principle.  Perhaps this [low-priority
> but tedious and extensive] change can be done at some point in the
> future...

Yes, it wouldn't hurt to change them all one day.


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

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