On Fri, Nov 23, 2007 at 02:37:47AM +0100 I heard the voice of
Richard Levitte, and lo! it spake thus:
>
> I generally agree. There's a lot of baggage, and I suspect some of
> it comes all the way from twm itself.
At least. I think some of it rode with William the Conqueror ;)
> I agree. To make it easy, we could add something similar to this
> (but with C instead of C++ style comments) at the end of each file:
[to mull over]
> > Similarly, cramming two statements on one line like
> > "i = 0; j = 0;" is usually more hinderance than help.
>
> Not sure I agree in all cases.
Well, I use them occasionally too. But saving 1 vertical line is such
a small gain that the first time it makes me mentally double-take,
it's already become a net loss.
> I try to keep lines at sub-80, but there are cases where doing so
> becomes butt ugly. Those are often better kept long.
Oh, certainly; formatting rules should never get in the way of making
code readable. But I don't think most of the violations of the 80-col
rule in the code base are the result of such considerations.
> Yes, more well placed comments good! Anyone feeling like
> documenting a piece of code somewhere with comments? By all the
> mighty gods, don't let anything stop you!
It's one thing that's vaguely on my todo list. I'd have to do all the
figuring-out work for any real new stuff I have in mind anyway, so...
Cleaning up code and adding comments is so much easier than actually
trying to unravel X11 to figure out how to add the capabilities I
occasionally wish for anyway ;)
> > - We have too damn many global variables.
>
> True, but they do serve a purpose.
Oh, absolutely. Global variables are very useful. But we've got a
wildly profane number of them, and I have a hard time believing that
even a quarter of them really belong.
> Well, I'd like to differenciate between statements (such as "if")
> and functions. The former gets a space, the latter not. That goes
> along with the BSD KNF style.
I've never seen that differentiation to bring me any value. I
mentally file it in the same category with the people carrying pikes
around to jam into the unwary who put ()'s on return statements.
> Now, what exactly is wrong with "else if"?
Oh, it's not 'else if'; it's the cuddling.
} else if((foo(bar) & baz) != (~FOO | baz)) {
As an Allmanite, I'd just write
}
else if((foo(bar) & baz) != (~FOO | baz))
{
Sticking K&R, you end up with
}
else if((foo(bar) & baz) != (~FOO | baz)) {
which looks ugly (just not as ugly as the cuddled).
> I generally agree, except CamelCase seems to be the general X11
> style. I've no problem adapting to that.
Theoretically, if we were to underscore all our functions, then the
difference would have the bonus of making it instantly clear which
functions are ours and which are Xlib. But I wouldn't recommend a
wholesale renaming; just a rule to stick by for new stuff, and maybe
occasionally shifting around the old.
> The former is yet one of those things that make me cringe. I can't
> see how it's hard to search the latter...
When grep yields me a couple screenfulls of results for a function,
it's awful hard to find which one is the definition.
> > - Implicit comparisons as boolean (e.g., "if(x)" instead of
> > "if(x!=NULL)" and equivalents for numerics) bad.
>
> Why?
Because they rely on side effects of conversion to a boolean
expression, and they don't make it clear exactly what you're testing
unless you already know exactly what the expression yields. With
explicit ">0" and "!=NULL", you do. And it can matter with signed
values; "!=0" and ">0" are two different assertions, but both evaluate
to true.
> > - I don't like multi-line comments that start on their first
> > line...
>
> Why?
They feel unbalanced, unless you end them on their last line, which
looks ugly too.
Ugly (with or without the leading * on following lines):
/* Make sure our WorkSpaceWindow is properly initialized.
* Otherwise we'll get uninitialized fields in it in
* situations. */
Unbalanced:
/* Make sure our WorkSpaceWindow is properly initialized.
* Otherwise we'll get uninitialized fields in it in
* situations.
*/
Much better:
/*
* Make sure our WorkSpaceWindow is properly initialized.
* Otherwise we'll get uninitialized fields in it in
* situations.
*/
> > - We should probably have less commented out code.
>
> I assume you're not talking about conditional code...
No, I mean pure commented out or #if 0'd code. See e.g.,
workmgr.c:1471
--
Matthew Fuller (MF4839) | [EMAIL PROTECTED]
Systems/Network Administrator | http://www.over-yonder.net/~fullermd/
On the Internet, nobody can hear you scream.
