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

**Hallvard B Furuseth** · Jul 4 '08, 04:05 PM

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

Nick Keighley writes:

On 4 Jul, 15:26, Hallvard B Furuseth <h.b.furus...@u sit.uio.nowrote :

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

>
what's wrong with that?!

Tab width 8 is the norm elsewhere, at least in the Unix world and with
published ASCII text. So some code gets written with tab-width 4, some
with 8. Even if everyone sets indentation = tab-width, code still gets
misaligned. This written with tab-width 4 (I've substituted spaces):

int foo; /* hi there */
const char *barbaz[256]; /* and here */

becomes this when displayed with tab-width 8:

int foo; /* hi there */
const char *barbaz[256]; /* and here */

>I'm sure that made sense once to save disk space for the
>source code, or something:-(

>
wouldn't replacing spaces with tabs do that?

Not if tab width indentation level. (e.g. 8 and 4).

Were disks ever *that* small? I've worked on old mini-computers and
even then we didn't try to save space at the *source* level.

Who knows. If the point was not to save space, I have no idea at all
what the point was.

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

>
use a decent configuration control system and make sure
you don't mix source code changes with reformats. Clearly label
the reformat versions.

Actually I'm not sure what a configuration control system is, as opposed
to source control. This project is still using CVS, and I'm not going
to fight about that. In any case the reformatting changes will
certainly not pay attention to the "don't reformat" rule:-)

--
Hallvard

**Johannes Bauer** · Jul 4 '08, 05:45 PM

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

Hallvard B Furuseth schrieb:

Who knows. If the point was not to save space, I have no idea at all
what the point was.

The point of using tabs is that everyone can easily convert to something
convenient. I find a value of 4 spaces perfect, some prefer 2, some
prefer 8. I've also seen 3.

You suggest that you switch to 8 spaces (i.e. no tabs) which seems to me
like a really not that good idea. After all everyone should be able to
display it the way he/she wants - not the way the programmer liked it.
Code indented by spaces is an annoying pest, IMHO.

Regards,
Johannes

--
"Wer etwas kritisiert muss es noch lange nicht selber besser können. Es
reicht zu wissen, daß andere es besser können und andere es auch
besser machen um einen Vergleich zu bringen." - Wolfgang Gerber
in de.sci.electron ics <47fa8447$0$115 45$9b622d9e@new s.freenet.de>

**zoot51** · Jul 4 '08, 10:05 PM

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

You suggest that you switch to 8 spaces (i.e. no tabs) which seems to me
like a really not that good idea. After all everyone should be able to
display it the way he/she wants - not the way the programmer liked it.
Code indented by spaces is an annoying pest, IMHO.

If you wish to maintain vertical aligment for whatever reason, then
you have to use spaces.

Of course having vertical alignment in source code is a matter of
personal taste

Reducing indent (tab) size increases the number of nested blocks that
dont require line wrapping, or allows the use of longer variable
names.

Increasing the indent size reduces the risk of vertical alignment
being upset if the tab size is changed as possibly only a single tab
is required to maintain alignment

**Jack Klein** · Jul 5 '08, 12:05 AM

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

On Fri, 4 Jul 2008 08:07:45 -0700 (PDT), Nick Keighley
<nick_keighley_ nospam@hotmail. comwrote in comp.lang.c:

On 4 Jul, 15:26, Hallvard B Furuseth <h.b.furus...@u sit.uio.nowrote :
>

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.

>
what's wrong with that?!
>
>

I'm sure that made sense once to save disk space for the
source code, or something:-(

>
wouldn't replacing spaces with tabs do that? Were disks ever
*that* small? I've worked on old mini-computers and even
then we didn't try to save space at the *source* level.

Apparently you never coded C under CP/M 80 on single density 8" floppy
disks.

Or Pascal on early micros where the storage medium was a cassette
tape. I say Pascal, because I don't actually remember a
cassette-based C for the original TRS-80.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.l earn.c-c++

http://www.club.cc.cmu.edu/~ajo/docs/FAQ-acllc.html

**Ian Collins** · Jul 5 '08, 01:45 AM

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

Jack Klein wrote:

On Fri, 4 Jul 2008 08:07:45 -0700 (PDT), Nick Keighley
<nick_keighley_ nospam@hotmail. comwrote in comp.lang.c:
>

>On 4 Jul, 15:26, Hallvard B Furuseth <h.b.furus...@u sit.uio.nowrote :
>>

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

>what's wrong with that?!
>>
>>

>>I'm sure that made sense once to save disk space for the
>>source code, or something:-(

>wouldn't replacing spaces with tabs do that? Were disks ever
>*that* small? I've worked on old mini-computers and even
>then we didn't try to save space at the *source* level.

>
Apparently you never coded C under CP/M 80 on single density 8" floppy
disks.
>

Forget the disks, getting the source in memory was enough of a challenge!

--
Ian Collins.

**Mark McIntyre** · Jul 5 '08, 10:55 AM

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

Johannes Bauer wrote:

Hallvard B Furuseth schrieb:
>

>Who knows. If the point was not to save space, I have no idea at all
>what the point was.

>
The point of using tabs is that everyone can easily convert to something
convenient. I find a value of 4 spaces perfect, some prefer 2, some
prefer 8. I've also seen 3.

Fortran lives !!

**Mark McIntyre** · Jul 5 '08, 11:05 AM

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

Hallvard B Furuseth wrote:

Nick Keighley writes:

>On 4 Jul, 15:26, Hallvard B Furuseth <h.b.furus...@u sit.uio.nowrote :

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

>what's wrong with that?!

>
Tab width 8 is the norm elsewhere, at least in the Unix world and with
published ASCII text.

Er no, but thats a religious war so don't go there.

So some code gets written with tab-width 4, some

with 8. Even if everyone sets indentation = tab-width, code still gets
misaligned. This written with tab-width 4 (I've substituted spaces):
>
int foo; /* hi there */
const char *barbaz[256]; /* and here */
>
becomes this when displayed with tab-width 8:
>
int foo; /* hi there */
const char *barbaz[256]; /* and here */

So reset your editor to use tab widths of 4. Job done.

**Hallvard B Furuseth** · Jul 5 '08, 04:05 PM

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

Mark McIntyre wrote:

>Hallvard B Furuseth wrote:

> So some code gets written with tab-width 4, some
>with 8. Even if everyone sets indentation = tab-width, code still gets
>misaligned. This written with tab-width 4 (I've substituted spaces):
> int foo; /* hi there */
> const char *barbaz[256]; /* and here */
>becomes this when displayed with tab-width 8:
> int foo; /* hi there */
> const char *barbaz[256]; /* and here */

>
So reset your editor to use tab widths of 4. Job done.

I should have clarified: The code was _originally_ written with tab
width 4. But by now it's sprinkled with quite a bit written with tab
widht 8. Open-source project, several authors... So it gets wrong
either way.

--
Hallvard

**Mark McIntyre** · Jul 6 '08, 12:25 AM

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

I should have clarified: The code was _originally_ written with tab

width 4. But by now it's sprinkled with quite a bit written with tab
widht 8. Open-source project, several authors... So it gets wrong
either way.

That doesn't make sense to me. A Tab is a tab - your editor should
convert 0x09 into whatever tabspace you've defined in your editor.

Presumably you mean that some moron has tab-to-spaced your code twice,
once at 4s/t and once at 8s/t.

In which case why not just run it through indent, setting appropriate
tabs (not spaces)?

**CBFalconer** · Jul 6 '08, 03:35 AM

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

Mark McIntyre wrote:

>

>I should have clarified: The code was _originally_ written with
>tab width 4. But by now it's sprinkled with quite a bit written
>with tab widht 8. Open-source project, several authors... So
>it gets wrong either way.

>
That doesn't make sense to me. A Tab is a tab - your editor should
convert 0x09 into whatever tabspace you've defined in your editor.
>
Presumably you mean that some moron has tab-to-spaced your code
twice, once at 4s/t and once at 8s/t.
>
In which case why not just run it through indent, setting
appropriate tabs (not spaces)?

Your software seems to be absorbing the message attributions.
Please fix.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home .att.net>
Try the download section.

**Hallvard B Furuseth** · Jul 6 '08, 04:55 PM

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

Mark McIntyre writes:

>I should have clarified: The code was _originally_ written with tab
>width 4. But by now it's sprinkled with quite a bit written with tab
>widht 8. Open-source project, several authors... So it gets wrong
>either way.

>
That doesn't make sense to me. A Tab is a tab - your editor should
convert 0x09 into whatever tabspace you've defined in your editor.

Yes, and either way existing code gets displayed misaligned.

Presumably you mean that some moron has tab-to-spaced your code twice,
once at 4s/t and once at 8s/t.

Maybe some places, but mostly "some moron" has written code which looks
fine with tab-width 8 but not 4. Maybe because it wasn't documented
anywhere that the code was written with tab-width 4.

If someone writes this with tab-width = indentation = 4, it gets aligned
fine:
int foo; /* ... */
struct Bar bar[256]; /* ... */
And if someone else writes this with tab-width = indentation = 8, it
gets aligned fine:
int baz; /* ... */
struct Bar quux[256]; /* ... */
but when you have both variants mixed up in the code base, there is no
tab-width which will align all of the code fine. With tab-width 8, the
first example looks like
int foo; /* ... */
struct Bar bar[256]; /* ... */
With tab-width 4, the 2nd example looks like
int baz; /* ... */
struct Bar quux[256]; /* ... */

Also, of course, occasional lines are indented with tabs+spaces
(tab-width 8, indentation 4).

In which case why not just run it through indent, setting appropriate
tabs (not spaces)?

First, I don't know how other people _write_ code, in particular with
non-Emacs. Thus the question of what kind of style is easy to produce
with other editors.

Second, because indent isn't smart enough. With macro magic, multiline
macros, too creative formatting and macros etc. So I'll have to walk
through the result and clean up. Like this piece of formatting which
is just semantically wrong:

/* try foo */
if (foo) {
handle foo;

/* otherwise try bar */
} else if (bar) {
handle bar;

/* oh dear */
} else {
error();
}

Also indent doesn't really understand C, so I suppose it could make
semantic changes. Not sure that's worth worrying about though.
Probably more likely that I'd make a typo when cleaning up.

--
Hallvard

**Hallvard B Furuseth** · Jul 6 '08, 04:55 PM

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

[Argh, forgot to untabify an example. Superseding article...]

Mark McIntyre writes:

>I should have clarified: The code was _originally_ written with tab
>width 4. But by now it's sprinkled with quite a bit written with tab
>widht 8. Open-source project, several authors... So it gets wrong
>either way.

>
That doesn't make sense to me. A Tab is a tab - your editor should
convert 0x09 into whatever tabspace you've defined in your editor.

Yes, and either way existing code gets displayed misaligned.

Presumably you mean that some moron has tab-to-spaced your code twice,
once at 4s/t and once at 8s/t.

Maybe some places, but mostly "some moron" has written code which looks
fine with tab-width 8 but not 4. Maybe because it wasn't documented
anywhere that the code was written with tab-width 4.

If someone writes this with tab-width = indentation = 4, it gets aligned
fine:
int foo; /* ... */
struct Bar bar[256]; /* ... */
And if someone else writes this with tab-width = indentation = 8, it
gets aligned fine:
int baz; /* ... */
struct Bar quux[256]; /* ... */
but when you have both variants mixed up in the code base, there is no
tab-width which will align all of the code fine. With tab-width 8, the
first example looks like
int foo; /* ... */
struct Bar bar[256]; /* ... */
With tab-width 4, the 2nd example looks like
int baz; /* ... */
struct Bar quux[256]; /* ... */

Also, of course, occasional lines are indented with tabs+spaces
(tab-width 8, indentation 4).

In which case why not just run it through indent, setting appropriate
tabs (not spaces)?

First, I don't know how other people _write_ code, in particular with
non-Emacs. Thus the question of what kind of style is easy to produce
with other editors.

Second, because indent isn't smart enough. With macro magic, multiline
macros, too creative formatting and macros etc. So I'll have to walk
through the result and clean up. Like this piece of formatting which
is just semantically wrong:

/* try foo */
if (foo) {
handle foo;

/* otherwise try bar */
} else if (bar) {
handle bar;

/* oh dear */
} else {
error();
}

Also indent doesn't really understand C, so I suppose it could make
semantic changes. Not sure that's worth worrying about though.
Probably more likely that I'd make a typo when cleaning up.

--
Hallvard

**Nick Keighley** · Jul 7 '08, 08:05 AM

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

On 6 Jul, 17:52, Hallvard B Furuseth <h.b.furus...@u sit.uio.nowrote :

Mark McIntyre writes:

I should have clarified: The code was _originally_ written with tab
width 4. But by now it's sprinkled with quite a bit written with tab
widht 8. Open-source project, several authors... So it gets wrong
either way.

>

That doesn't make sense to me. A Tab is a tab - your editor should
convert 0x09 into whatever tabspace you've defined in your editor.

>
Yes, and either way existing code gets displayed misaligned.
>

Presumably you mean that some moron has tab-to-spaced your code twice,
once at 4s/t and once at 8s/t.

>
Maybe some places, but mostly "some moron" has written code which looks
fine with tab-width 8 but not 4. Maybe because it wasn't documented
anywhere that the code was written with tab-width 4.
>
If someone writes this with tab-width = indentation = 4, it gets aligned
fine:
int foo; /* ... */
struct Bar bar[256]; /* ... */
And if someone else writes this with tab-width = indentation = 8, it
gets aligned fine:
int baz; /* ... */
struct Bar quux[256]; /* ... */
but when you have both variants mixed up in the code base, there is no
tab-width which will align all of the code fine. With tab-width 8, the
first example looks like
int foo; /* ... */
struct Bar bar[256]; /* ... */

I think I could live with that...

With tab-width 4, the 2nd example looks like
int baz; /* ... */
struct Bar quux[256]; /* ... */
>
Also, of course, occasional lines are indented with tabs+spaces
(tab-width 8, indentation 4).
>

In which case why not just run it through indent, setting appropriate
tabs (not spaces)?

no. *remove* all the tabs. Its the tabs that cause the problem.

First, I don't know how other people _write_ code, in particular with
non-Emacs. Thus the question of what kind of style is easy to produce
with other editors.

Does emacs format your code that much? The editor I use fiddles
with the indentation a bit but otherwise leaves things alone
(if it tried to do anything else the feature would be rapidly
disabled- or the editoe dumped).

Second, because indent isn't smart enough. With macro magic, multiline
macros, too creative formatting and macros etc. So I'll have to walk
through the result and clean up.

I havn't used indent for a while but generally I thought it was pretty
good.
It tended to messs up some of my comment blocks.

> Like this piece of formatting which
is just semantically wrong:

*semantically* wrong? Why? I hate K&R style { on the same
line as the code and comments outside the block. But the semantics
seem
plain enough.

/* try foo */
if (foo) {
handle foo;
>
/* otherwise try bar */
} else if (bar) {
handle bar;
>
/* oh dear */
} else {
error();
}

with my layout this would look like this.

if (foo)
{
handle foo;
}
else if (bar)
{
handle bar;
}
else
{
error();
}

or even

if (foo)
handle foo;
else if (bar)
handle bar;
else
error();

is *that* "semantical ly* wrong? I'm beginning to wonder
if one of us has a non-standard meaning for "semantic". ..

Also indent doesn't really understand C,

ok...

so I suppose it could make
semantic changes.

not by *my* definition of "semantic". I've never seen
indent screw up a correct peoce of code. The layout may
be strange but in my experience the code did the same thing
before and after.

Not sure that's worth worrying about though.

it would sure worry me if it was happening!

Probably more likely that I'd make a typo when cleaning up.

yes

--
Nick Keighley

"To every complex problem there is a simple solution... and it is
wrong."
-- Turski

**Hallvard B Furuseth** · Jul 7 '08, 12:55 PM

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

Nick Keighley writes:

>On 6 Jul, 17:52, Hallvard B Furuseth <h.b.furus...@u sit.uio.nowrote :
>(...)

>With tab-width 8, the
>first example looks like
> int foo; /* ... */
> struct Bar bar[256]; /* ... */

>
I think I could live with that...

Well, two lines are hardly a problem. 20 gets a bit more annoying.

>>Mark McIntyre writes:

>>In which case why not just run it through indent, setting appropriate
>>tabs (not spaces)?

>
no. *remove* all the tabs. Its the tabs that cause the problem.

Well, that's one option.
If people refrain from re-inserting tabs...

>First, I don't know how other people _write_ code, in particular with
>non-Emacs. Thus the question of what kind of style is easy to produce
>with other editors.

>
Does emacs format your code that much? The editor I use fiddles
with the indentation a bit but otherwise leaves things alone
(if it tried to do anything else the feature would be rapidly
disabled- or the editoe dumped).

Emacs is programmable and very (too?) configurable, there is e.g. a
key binding to re-indent a block of code according to my chosen style.
In C files, the Tab key by default re-indents the line. It can be
configured to not do that, or to only do it when there is only
whitespace to the left of the cursor. Or I could write a function
which inserts spaces following non-tab characters but tab otherwise.
There is a key which inserts /* */ at the configured comment column
or moves an existing comment to that column. Etc.

I've hardly used other editors for C files, so I don't know how much
help they give and what kind of styles are natural to produce with
those. (E.g. if "indent with tab, align to a configured comment column
with spaces" is easy.)

>> Like this piece of formatting which is just semantically wrong:

>
*semantically* wrong? Why? I hate K&R style { on the same line as the
code and comments outside the block. But the semantics seem plain
enough.

I meant the comment for one if-test is inside the previous {}, so there
little reason to expect any program to be able to indent it right.
Indentation gives (editing the quoted text a bit):

/* try foo */
if (foo) {
handle foo;

/* otherwise try bar */ <<< whoops <<<
} else if (bar) {
handle bar;
(...)

Yet it would have been so easy to write it "indent-friendly":

/* try foo */
if (foo) {
handle foo;
}

/* otherwise try bar */
else if (bar) {
handle bar;
(...)

>

>Also indent doesn't really understand C,

>
ok...
>

>so I suppose it could make semantic changes.

>
not by *my* definition of "semantic". I've never seen
indent screw up a correct peoce of code. The layout may
be strange but in my experience the code did the same thing
before and after.

I've seen old documentation that warned that it could happen.
Getting confused and inserting/removing whitespace in strings or macro
arguments, or something. However I expect the keyword here is "old".

>Probably more likely that I'd make a typo when cleaning up.

>
yes

--
Hallvard

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

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

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment