reformat to tool/editor-compliant C style?

I'd like to reformat an open source package (LDAP) to a new C style.
8M code, 0.3M lines. With some currently hopeless formatting rules like
tab-width=4. I'm sure that made sense once to save disk space for the
source code, or something:-( The project's normal rule is "don't
reformat unnecessarily" since it makes source control merge/diff
difficult. That hasn't helped the style over time either.

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 clever ideas to
keep future code more or less conformant to the chosen style, without
getting too anal about it?

I thought I'd just pick something close to Emacs "stroustrup" style and
give Indent the options for that, but at least Gnu Indent isn't willing
to produce just the same. In particular, it aligns variable
declarations like this:
int foo;
int **bar;
with the declared identifier aligned. Which is cool, but it's not what
one naturally produces with an editor. Have I missed some Indent option
to prevent it? some other indent program, maybe? are there
"active" Emacs and Vi modes that help produce this?

I don't see much point in re-indenting to some indentation style only to
see newly written code immediately deviate from it. Though I guess one
could just say "follow The Style everyone" and be anal about it.

maybe we should just not indent variable and struct member names:-(
Looks far less readable to me though.


We'll likely keep some quirks of the current formatting anyway, like
foo_bar_baz(one, two,
three);
instead of
foo_bar_baz(one, two,
three);
due to long functions with long parameter lists passed long argument
names.


How much work am I looking at? Have anyone here done a similar job? I
don't normally put too much work into LDAP over a short time. Even
with Indent it looks like it'll be a fair amount of work to re-indent
and then prettify what Indent produces. In particular comments and the
too many deeply nested functions. the other hand, the job of
splitting up big functions and making sure the change really didn't
affect program logic looks tedious too. I can't test all the changes
either, and I have no idea how some of the code works.

And the headers will likely have to be done by hand anyway, due to macro
magic in public declarations.

--
Hallvard

Hallvard B Furuseth wrote:

In particular, it aligns variable
declarations like this:
int foo;
int **bar;
with the declared identifier aligned. Which is cool, but it's not what
one naturally produces with an editor.

FWIW, that's what I naturally do :)

--
Pietro Cerutti

Pietro Cerutti wrote:
Hallvard B Furuseth wrote:
>
>In particular, it aligns variable
>declarations like this:
>int foo;
>int **bar;
>with the declared identifier aligned. Which is cool, but it's not what
>one naturally produces with an editor.
>
FWIW, that's what I naturally do :)

I frequently use vertical alignment
to highlight sameness and contrast differences
in consecutive lines of source code.

--
pete

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, IMH

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

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

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

Hallvard B Furuseth wrote:
I'd like to reformat an open source package (LDAP) 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.

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. project, several authors So it gets wrong
either way.

--
Hallvard

I wrote:

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

, I've seriously miscommuniated here

If I do this, I'll reformat the code to what will become the project's
new style, and commit the results. Assuming it gets Ked. When the
changes quiet down we'll presumably go back to the "don't reformat
unnecessarily" rule.

The project probably had a consistent style once. Who knows what it was
exactly. Currently it's not consistent. The code looks best with
tab-width 4, but some of it has tab-width 8. There are strange spacing
conventions around parens - often space inside parens, except when there
aren't. Function names start at first column, except when they don't

I suppose a new project rule could be "always use indent before
committing, except for .h files."

Anyway, tab-width 4 seems to be the major reason the style grows
inconsistent. Code written with tab-width 8 does get committed every
now and then. And we're mainly Unix people. So -

Mark McIntyre wrote:
>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.

Actually, please go there. If I can _not_ expect consistency to improve
if I reformat with width 8, I'd certainly like to know. I know Windows
is different, but I thought that was with richer formats than ASCII.

Still, yeah, I was afraid "this is a waste of time" would be the correct
answer.


Johannes Bauer wrote:
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.

That's a good point, and it'd have worked if the code had not followed
non-whitespace with tabs for alignment.

I notice uncrustify which Roland posted can help with that - it has
options to indent with tabs but align with spaces. Thanks!

Also it might make the job more manageable to get rid of lines that
depend on tab-width - e.g. move comments from the right of code to the
previous line.

You suggest that you switch to 8 spaces (i.e. no tabs) which seems to me
like a really not that good idea.

That's not what I meant, I just wanted to illustrate what some of the
code looked like. Whatever tab-width I choose.

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, IMH

Well, after I was done it'd be indented by both spaces and tabs. Unless
I rearrange it to primarily have indent-width = tab-width = 8 and
hopefully work otherwise. Would need to split functions so they don't
run past 80 chars though

--
Hallvard

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

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

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

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, IMH

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

Richard wrote:
I strongly advise against using tabs. Any editor worth its salt treats
spaces like tabs.

Well, I disagree. In my opinion ease of editing with the simplest editor
should be the goal here (to make the code "editor independent"). In this
case tabs are preferable.


August