I wrote:
Okay, 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 OKed. 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:
>
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:
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.
That's not what I meant, I just wanted to illustrate what some of the
code looked like. Whatever tab-width I choose.
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'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. (...)
8M code, 0.3M lines. With some currently hopeless formatting rules like
tab-width=4. (...)
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 OKed. 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.
>with published ASCII text.
Er no, but thats a religious war so don't go there.
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.
convenient. I find a value of 4 spaces perfect, some prefer 2, some
prefer 8. I've also seen 3.
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.
like a really not that good idea.
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, IMHO.
not the way the programmer liked it. Code indented by spaces is an
annoying pest, IMHO.
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
Comment