libclc-developers — Communication between developers of libclc

[Libclc-developers] Re: code layout

[Hallvard B F. <h.b...@us...>]

This is a reply to message
   https://sourceforge.net/forum/message.php?msg_id=1917616
by augestad.

> This way of discussing [in the web forum] is hard, given the tools
> available. How about taking it to libclc-developers mailing list?

Done.

> Hard to reply here, news is a better format/tool.

Can we kill the web forum and just use the mailinglist and/or a
newsgroup (alt.comp.libclc)?

>> --no-space-after-if
>> 
>> I vote against this one. (...)
> 
> Not a big issue, IMO. The major reasons I prefer it that way is that
> is:
>
> a) Multiline if's align well without the space
> if(clc_foo(many args here)
> || clc_bar(even more here)) 
>
> clc_foo() and clc_bar will be aligned.

No indentation of the continuation line?  That's the ugliest way to
format a multi-line if I've seen yet...
Anyway, indent with your suggested options doesn't produce that.  It
changes your code to align the '||' with 'clc_foo':

  if(clc_foo(many args here)
     || clc_bar(even more here))

> b) Assignments within the if-statements look better, esp if we use one
> space in front of the second (
>    if( (a = clc_foo(bar)) == NULL) ...

Indent removes the space in front of the alignment.  Which is how I like
it:-) I think we should mostly avoid assignments in if statements, BTW.

> This is the style used in all of Stevens' books. Too many spaces if we
> write:
> if ( (a = clc_foo(bar)) == NULL) ..

Yes, I'd write 'if ((a = ...))'.

>> --tab-size 4
>> 
>> Please, please don't.  (...)
> 
> boa: This is mainly indented for posting code.

Yes, that's another place it causes problems...

> boa: ts 4 causes no problem for anyone since we keep tabs
> anyway. I''ve never experienced alignmend problems with tabs, and
> multiline statements align perfectly.

I'm not sure what you mean by that, but: I should have said, the
problems I referred to happen for people with tab-with 8 (which is most
people, I believe) when they read code written with tab-width 4.

E.g. this code:

int i;							/* some variable with a short name */
int longer_variable_name;		/* some other variable */

void foo(void)
{
	while (clc_foobar() && (some_long_expression(more, more, more)
							|| yet_some_more())) {
		oops();
	}
}

is formatted with your indent options, with tab width 4.  With tab-width
8, it looks like this:

int i;                                                  /* some variable with a short name */
int longer_variable_name;               /* some other variable */

void foo(void)
{
        while (clc_foobar() && (some_long_expression(more, more, more)
                                                        || yet_some_more())) {
                oops();
        }
}

The 'int i' line gets too long because the tabs before the comment are
too wide with tab-width 8.  The two comments were aligned with tab-with
4, but are misaligned with width 8 because of the tabs from the end of
'i;' to the end if 'longer_variable_name;'.  The '||' was aligned with
'some_long_expression', but with longer tabs, it got misaligned.

And God help us if a file is written by people with one tab-width and
modified by someone with another tab-width, though that can be fixed by
always running indent with whatever options we choose for libclc on code
which is checked into CVS.

If you have configured your tools to use tab-width 4 and want to stay
that way, I suggest we add the indent option --no-tabs (-nut) so people
won't mess up for each other with conflicting tab-widths.  And to always
re-indent code which is checked in.

> We don't align function parameters like this:
> int clc_foo(const char* a,
>                 int b, 
>                 const char* c)
> 
> This destroys the ability to customize tab size.

That has nothing to do with tab size.  The format produced by
indentation is described by how many spaces are used in various places.
Tab size just says how many spaces are replaced with one tab, after
indentation is done.

> It also sucks if you change the function name or
> return type, since you then must realign the
> other lines.

Unless we use --procnames-start-lines (-psl).

I don't see the problem with having to realign now and then, BTW.  Just
run indent again.  We won't change function names that often anyway.

> We do it like this instead:
> int clc_foo(
>     const char *a,
>     int b,
>     const char* c)

Then you need to add the option --break-function-decl-args (-bfda).

-- 
Hallvard

[Libclc-developers] Is this thing on?

[Bryan D. <bd...@bd...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Anyone using this list yet?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+X8B4x533NjVSos4RAsLtAJ9ZE+QPrRfoEWwTXeORYqg+FLw+egCgkWkM
KngH56MQDvicT8QJauccUho=
=uzzN
-----END PGP SIGNATURE-----