On Tue, Dec 04, 2007 at 07:58:02AM +0100 I heard the voice of
Richard Levitte, and lo! it spake thus:
>
> I don't agree with that, as tally clearly has a boolean intent.
Ah, but it doesn't; it's ++'d, not =1'd. Clearly it's a counter, not
a boolean.
> "if (!tally)" could as well be "if (buf[0] == '\0')"
But it could as well be "if (!buf[0])" too. Where do you draw the
line?
> That's misuse of a tristate value. It can't be used as a boolean.
> This is a case where I agree with you.
Well, but I see it (as well as the above) as the same case. It most
certainly can be used as a 'boolean' in the C if() manner, since it
returns something that can get treated as a number. And I've seen it
so used more times than I have the stomach lining to recall. It's
more amenable to such treatment than a pointer, come to that; it's
only a tri-state, not a 2**32 (or 2**64, for that matter)-state
> If you know C (and no, your brain doesn't have to be a C compiler),
> the meaning is obvious.
Well, I like to think I know C. I've been doing it since before I did
any other language (well, except BASIC, but I did the 12-step program
and recovered from that after I picked up C. I swear I haven't
touched it since!). But that construct never sat well with me; it
always makes my brain lurch.
> fullermd> a fair number of C coding standards I've seen mandate no
> fullermd> explicit comparison for obvious predicates, and require the
> fullermd> comparison when it's not).
>
> Actually, I like that. Now, all we need to clear is what
> constitutes the grey area of what is obvious and what is not.
Oh, well, that's the crux of the disagreement, isn't it? ;)
To me, if it's not fairly obviously (to the glance) and correctly (to
code tracing) boolean, it doesn't belong bare in a conditional.
Variables/functions with names like "isallowed" or "can_access()" meet
the first criterion (and hopefully meet the second, or the implementor
gets the Board Of Education across the back). Statements around
binary comparison operators like == and < meet both.
If CtwmSetVScreenMap()'s 'tally' were called something like
'hasnames', it would satify the first condition. And if it were =1'd
instead of ++'d, it would satify the second. It would still be an
unnecessary variable, of course :]
To me, though, things like pointers and non-bistate numeric types fail
both; that they work is a side effect (intentional though it may be)
of C's lacking a real boolean type and so treating other types as if
they implicitly were such.
I suspect that we've plowed this furrow pretty well by now, though. I
think we're doomed to disagree. Worse, I think I'm outvoted :(. So,
do you want to declare a Project Style on it, or leave it open? I'd
suggest at least bounding marks on both sides, even if the middle is
left to discretion. e.g.:
- DO NOT use explicit tests on obvious predicates:
if(user_can_change(this)==1) /* BAD */
if(user_can_change(this)) /* GOOD */
- DO use explicit tests on functions that don't return intentionally
(and obviously?) boolean values:
while((tmp = get_next_window())) /* BAD */
while((tmp = get_next_window()) != NULL) /* GOOD */
if(!strcmp(x, y)) /* BAD */
if(strcmp(x, y)!=0) /* GOOD */
- [everything else]
Probably should move on to the other (and largely most substantive)
style questions...
--
Matthew Fuller (MF4839) | [EMAIL PROTECTED]
Systems/Network Administrator | http://www.over-yonder.net/~fullermd/
On the Internet, nobody can hear you scream.
