pilot-db-list

[pilot-db-list] CVS indentation strategy

[Nathan K. <na...@ve...>]

As I start to do things with the CVS repository, it's apparent that
Scott and Tom had different opinions on how indent C code.  The
obvious difference is that Scott preferred 8 space indents, while the
rest of the code (presumably mostly Tom's) has 4 space indents.

The current code is often hard to read, because the indentation might
change several times withing a given function.  Personally, I prefer
GNU style with 2 space indents, but changing over to this would be
silly.  So what is to be done?  My impulse is to restandardize to
Tom's original 4 space indentation.

The arguments against standardizing it now is that the CVS changes for
the indentation will mask the CVS changes that might give good clues
when one is searching for the cause of a recent bug.  The argument for
standardizing now is that we are at a point we almost all the code in
there is suspect, so when would be better than the present.

Thoughts appreciated, although practical suggestions would be
appreciated more than blind zealotry.  Left to my own devices, I'll
probably just start re-indenting files before I start working on them,
checking them in, and then checking my changes in on top of that.

--nate

Re: [pilot-db-list] CVS indentation strategy

[Tony M. <to...@ki...>]

We'd never get a standardized indentation style working.  I personally 
have used four spaces (no tabs) for decades, along with the old 
structured-C style braces (braces on their own lines), and find the BSD 
style function header line of type\nname(args){\n utterly 
incomprehensible even though I do a lot of commercial work on BSD. 

The open-source world is full of opinions, but there's no way to enforce 
a standard when all the work is charity.  So I would say do whatever you 
feel necessary for legibility and always use the -w parameter with cvs 
diff.  (That ignores all whitespace differences.)

Nathan Kurz wrote:

>As I start to do things with the CVS repository, it's apparent that
>Scott and Tom had different opinions on how indent C code.  The
>obvious difference is that Scott preferred 8 space indents, while the
>rest of the code (presumably mostly Tom's) has 4 space indents.
>
>The current code is often hard to read, because the indentation might
>change several times withing a given function.  Personally, I prefer
>GNU style with 2 space indents, but changing over to this would be
>silly.  So what is to be done?  My impulse is to restandardize to
>Tom's original 4 space indentation.
>
>The arguments against standardizing it now is that the CVS changes for
>the indentation will mask the CVS changes that might give good clues
>when one is searching for the cause of a recent bug.  The argument for
>standardizing now is that we are at a point we almost all the code in
>there is suspect, so when would be better than the present.
>
>Thoughts appreciated, although practical suggestions would be
>appreciated more than blind zealotry.  Left to my own devices, I'll
>probably just start re-indenting files before I start working on them,
>checking them in, and then checking my changes in on top of that.
>
>--nate
>  
>

Re: [pilot-db-list] CVS indentation strategy

[Mariusz S. <MSt...@zn...>]

	As a new (and very impressed) user of Pilot-DB, I have just subscribed
to this list, so hello all.
	The subject of coding style, as much as a choice of an programmer's
editor has been a flash point for many a flame war, yet the idea of coding
standardization is a compelling one, but a choice (any choice!) of even
among the four major (not counting variants) coding styles will leave the
proponents of the other three less happy.
	There is a solution, though, that bypasses the whole issue; namely,
source code reformatters.  One particular implementation of this idea has
served me well over the years in the Windows environment (*nix has a
similar one (part of GNU utilities) which name escapes me now).  Christophe
Beaudet' s GC (for Great Code) can be found at
http://perso.club-internet.fr/cbeaudet is NOT an open source utility, but
is free to use.  It is a very versatile command line utility that does a
near perfect (you know, like that 99% accuracy OCR) job.  No, really; It
has very few quirks, and it excels at straight C code... good enough to do
a wholesale batch convert between styles.

/Mariusz

P.S. Is there a way to get past posting to this list... Mailman comes up
short on this.

On Sat, 21 Feb 2004 20:33:11 -0800, Tony McNamara wrote:

>We'd never get a standardized indentation style working.  I personally 
>have used four spaces (no tabs) for decades, along with the old 
>structured-C style braces (braces on their own lines), and find the BSD 
>style function header line of type\nname(args){\n utterly 
>incomprehensible even though I do a lot of commercial work on BSD. 
>
>The open-source world is full of opinions, but there's no way to enforce 
>a standard when all the work is charity.  So I would say do whatever you 
>feel necessary for legibility and always use the -w parameter with cvs 
>diff.  (That ignores all whitespace differences.)

Re: [pilot-db-list] CVS indentation strategy

[Emmanuel S. <se...@wa...>]

On Sat, Feb 21, 2004 at 08:51:22PM -0700, Nathan Kurz wrote:
>
> As I start to do things with the CVS repository, it's apparent that
> Scott and Tom had different opinions on how indent C code.  The
> obvious difference is that Scott preferred 8 space indents, while the
> rest of the code (presumably mostly Tom's) has 4 space indents.

I'm more of a K&R style (8 space indents, braces on the end of the line)
fan myself but hey...

> The current code is often hard to read, because the indentation might
> change several times withing a given function.  Personally, I prefer
> GNU style with 2 space indents, but changing over to this would be
> silly.  So what is to be done?  My impulse is to restandardize to
> Tom's original 4 space indentation.

Probably best to change to whatever is more present in the code at the
moment. Makes for less work.

> Thoughts appreciated, although practical suggestions would be
> appreciated more than blind zealotry.  Left to my own devices, I'll
> probably just start re-indenting files before I start working on them,
> checking them in, and then checking my changes in on top of that.

This is absolutely vital, IMHO.
Submit a indentation fix to CVS, noting in the logs that there has been
no code change then make a second commit with your changes.

Emmanuel