Re: reformat to tool/editor-compliant C style?

[Mark McIntyre]

Hallvard B Furuseth wrote:

I'd like to reformat an open source package (OpenLDAP) to a new C style.
8M code, 0.3M lines. With some currently hopeless formatting rules like
tab-width=4.

Setting aside that 4 is an entirely sensible tab width...

The project's normal rule is "don't
reformat unnecessarily" since it makes source control merge/diff
difficult.

This seems to be the showstopper. Unless you now entirely own the code
yourself alone, don't reformat it it, will merely annoy the
collaboration team.

Anyway, can someone recommend a "tool-friendly" style, which Indent,
Emacs, Vi or whatever all can be easily configured to produce? Doesn't
hurt if whatever is used on Windows can it too.

Any style can be used on any platform. if you absolutely MUST do this,
pick your favourite and go for it.

How much work am I looking at? Have anyone here done a similar job?

Yes once. Almost at once I realised it was an utter waste of my time.
Even with the best tools, you spend hours manually frigging with the
code to get it to your personal preference. At some point you hopefully
realise you are rearranging the chairs on the boat-deck.

Instead I merely inserted whitespace and braces where the previous
maintenance droid had been overeconomical
int i=j++&&k||z(foo ,f->d>e)&&34)/q+564/z(fr&fq++);//huh?

Even with Indent it looks like it'll be a fair amount of work to re-indent
and then prettify what Indent produces.

Frankly it'll be a complete waste of time. Does the code fail to run
because of the formatting? No. So mildly reformat bits which are hard to
read as-and-when you need to for maintenance purposes.

[Keith Thompson]

Re: reformat to tool/editor-compliant C style?

Mark McIntyre <markmcintyre@T ROUSERSspamcop. netwrites:

Hallvard B Furuseth wrote:

>I'd like to reformat an open source package (OpenLDAP) to a new C style.
>8M code, 0.3M lines. With some currently hopeless formatting rules like
>tab-width=4.

>
Setting aside that 4 is an entirely sensible tab width...

Perhaps so, but every Unix tool I know of uses a *default* tab width
of 8 columns. I don't want to have to re-configure vim, or emacs, or
less, or enscript, or ..., for each source file I want to look at.

The only reasonable solutions are (a) enforce a consistent tab width
(which needn't match the indentation width), or (b) don't use tabs at
all.

Once upon a time, I used (a). In vi, I had the tab width set to 8,
and the indentation level set to 2, 3, or 4 at various times (these
days I use 4 consistently). Indentation was done with a mix of tabs
and spaces. It worked for me, but it didn't mix will with other
people using different tab widths.

Now I use (b), and that's what I recommend. I have vim configured so
it never inserts a tab character unless I explicitly tell it to, and I
have a two-character macro that runs the current file through
"expand".

My recommendation for Hallvard:

For each source file, figure out what tab width is being used (this
could be tricky). Filter each file through "expand -t N", where N is
4 or 8 as appropriate. Check the modified files into CVS with a
comment making it clear that tab expansion is the only change. If you
do any other reformatting (brace style, etc.), do that as a separate
checkin. Then start enforcing a "no tabs" rule; all indentation must
be done using spaces only (except in Makefiles, which require tabs --
sigh).

I think CVS can be configured to run a command on a file automatically
as it's being checked in. Making use of this feature (or not) is left
as an exercise.

(Just in case it wasn't already clear, the above is my opinion. It's
based on many years of experience, but I'm sure plenty of smart people
will disagree.)

--
Keith Thompson (The_Other_Keit h) kst-u@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Richard Tobin]

Re: reformat to tool/editor-compliant C style?

In article <lnskukxpvg.fsf @nuthaus.mib.or g>,
Keith Thompson <kst-u@mib.orgwrote:

>Perhaps so, but every Unix tool I know of uses a *default* tab width
>of 8 columns.

This just reflects early VDUs, which in turn imitated physical
printing devices, and was intended for type-written tables and
the like, and has little to do with programming languages.

-- Richard
--
Please remember to mention me / in tapes you leave behind.

[Richard Bos]

Re: reformat to tool/editor-compliant C style?

richard@cogsci. ed.ac.uk (Richard Tobin) wrote:

Keith Thompson <kst-u@mib.orgwrote:
>

Perhaps so, but every Unix tool I know of uses a *default* tab width
of 8 columns.

>
This just reflects early VDUs, which in turn imitated physical
printing devices, and was intended for type-written tables and
the like, and has little to do with programming languages.

This is true; and this is why in programming, one should not use tabs,
which are built for typewriting.

Richard

[Keith Thompson]

Re: reformat to tool/editor-compliant C style?

richard@cogsci. ed.ac.uk (Richard Tobin) writes:

In article <lnskukxpvg.fsf @nuthaus.mib.or g>,
Keith Thompson <kst-u@mib.orgwrote:
>

>>Perhaps so, but every Unix tool I know of uses a *default* tab width
>>of 8 columns.

>
This just reflects early VDUs, which in turn imitated physical
printing devices, and was intended for type-written tables and
the like, and has little to do with programming languages.

Agreed -- but that's just the historical context. It's still the case
that (a) setting hard tabstops at anything other than the default 8
columns causes problems viewing and manipulating source files that
contain tabs, and (b) the best solution, IMNSHO, is to avoid using
tabs in source files.

--
Keith Thompson (The_Other_Keit h) kst-u@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"