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

[Nick Keighley]

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.

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.

can't help you with indent

<snip>

--
Nick Keighley

[CBFalconer]

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]

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]

[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]

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]

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

[Mark McIntyre]

Hallvard B Furuseth wrote:

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

its ok, I realised what you meant and in fact it worked on my display.

Also indent doesn't really understand C, so I suppose it could make
semantic changes.

I've /never/ heard of it doing that. It also understands C fine, afaik.

--
Mark McIntyre

CLC FAQ <http://c-faq.com/>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt >

[August Karlstrom]

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.

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.

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

[CBFalconer]

August Karlstrom wrote:

>

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

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

[Richard]

August Karlstrom <fu********@com hem.sewrites:

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.

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.

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.