By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
445,885 Members | 1,499 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 445,885 IT Pros & Developers. It's quick & easy.

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

P: n/a
On 4 Jul, 15:26, Hallvard B Furuseth <h.b.furus...@usit.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
Jul 4 '08 #1
Share this Question
Share on Google+
18 Replies


P: n/a
Nick Keighley writes:
On 4 Jul, 15:26, Hallvard B Furuseth <h.b.furus...@usit.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
Jul 4 '08 #2

P: n/a
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.electronics <47***********************@news.freenet.de>
Jul 4 '08 #3

P: n/a
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
Jul 4 '08 #4

P: n/a
On Fri, 4 Jul 2008 08:07:45 -0700 (PDT), Nick Keighley
<ni******************@hotmail.comwrote in comp.lang.c:
On 4 Jul, 15:26, Hallvard B Furuseth <h.b.furus...@usit.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.learn.c-c++
http://www.club.cc.cmu.edu/~ajo/docs/FAQ-acllc.html
Jul 5 '08 #5

P: n/a
Jack Klein wrote:
On Fri, 4 Jul 2008 08:07:45 -0700 (PDT), Nick Keighley
<ni******************@hotmail.comwrote in comp.lang.c:
>On 4 Jul, 15:26, Hallvard B Furuseth <h.b.furus...@usit.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.
Jul 5 '08 #6

P: n/a
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 !!
Jul 5 '08 #7

P: n/a
Hallvard B Furuseth wrote:
Nick Keighley writes:
>On 4 Jul, 15:26, Hallvard B Furuseth <h.b.furus...@usit.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.
Jul 5 '08 #8

P: n/a
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
Jul 5 '08 #9

P: n/a
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)?

Jul 6 '08 #10

P: n/a
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.
Jul 6 '08 #11

P: n/a
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
Jul 6 '08 #12

P: n/a
[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
Jul 6 '08 #13

P: n/a
On 6 Jul, 17:52, Hallvard B Furuseth <h.b.furus...@usit.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* "semantically* 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

Jul 7 '08 #14

P: n/a
Nick Keighley writes:
>On 6 Jul, 17:52, Hallvard B Furuseth <h.b.furus...@usit.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
Jul 7 '08 #15

P: n/a
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>
Jul 7 '08 #16

P: n/a
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
Jul 8 '08 #17

P: n/a
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.
Jul 8 '08 #18

P: n/a
August Karlstrom <fu********@comhem.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.
Jul 8 '08 #19

This discussion thread is closed

Replies have been disabled for this discussion.