reformat to tool/editor-compliant C style?

[CBFalconer]

.... snip ...

I agree wholeheartedly. It is more flexible to use logical indentation
steps (tabs). Moreover, tabs are easier to edit than sequences of spaces
when you do not rely on automatic indentation. To make editing with a
simple editor easier I also never insert newlines in comment paragraphs
but use line wrapping instead.

Ugh.

 

[Keith Thompson]

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

 

[Richard]

I agree wholeheartedly. It is more flexible to use logical indentation
steps (tabs). Moreover, tabs are easier to edit than sequences of
spaces when you do not rely on automatic indentation. To make editing
with a simple editor easier I also never insert newlines in comment
paragraphs but use line wrapping instead.


August

Absolute and total nonsense. This might have been true when working in
the stone age. No decent editor worth its salt cant not "mimic" tabs
indenting or outdenting using spaces.

 

[Richard Tobin]

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

 

[Richard Bos]

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]

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.