S
stremler
[chop - putting the constant first in a comparison]b e g i n quoting Richard Heathfield said:
Out of curiosity, how do you read "=="?
Do you "equals", or "is equal to", or something else entirely?
Out of curiosity, how do you read "=="?
Do you "equals", or "is equal to", or something else entirely?
D
Dave Hansen
I used to feel that way. But I'm not so sure any more. I'm coming
around again on "harming readability is harmful."
Several months ago, I started working for a new employer where the
above idiom is encouraged (but, thank God, not required) by the coding
standard. That, combined with some other "suggestions" in the coding
standard, results in such wonderful code as
if (FALSE != is_complete)
Again, that's fortunately not _required_, but it does cause
confusion. For example, at a recent code review, I was the only (of
three) reviewers who caught a logic error with a statement similar to
the above. And I had to explain step-by-step to one of the other
reviewers (no dummy, just experiencing a brain fart) why the above was
equivalent to "if (is_complete)" and not "if (!is_complete)".
For the record, no one would have been confused by the simpler
statement.
Again, the only reason I can imagine that any C programmer wouldn't
lint his code is pride: they can't stand _anyone_ telling them their
code sucks. Lint early, lint often, lint is your friend.
Regards,
-=Dave
R
Richard Heathfield
(e-mail address removed) said:
I read it as "==", believe it or not.
If you're asking how I translate it into English when reading code
aloud, (a) I hardly ever do, but (b) when I do, I render it as "is
equal to" or "has the same value as".
I read it as "==", believe it or not.
If you're asking how I translate it into English when reading code
aloud, (a) I hardly ever do, but (b) when I do, I render it as "is
equal to" or "has the same value as".
K
Keith Thompson
I rarely read C code out loud. When I read it silently, sometimes
it's "equals", sometimes it's "is equal to", sometimes it's just "==".
K
Keith Thompson
[...]Dave Hansen said:
The real sin in that code is not the reversal of the operands, it's
the explicit comparison to FALSE. Writing
if (is_complete != FALSE)
isn't much better. To repeat an old argument, if you think that
if (is_complete != FALSE)
is better than
if (is_complete)
then you should think that
if ((is_complete != FALSE) != FALSE)
is even better.
(I would guess that the reversal of the operands might have
contributed to your colleague's brain fart, but it's hard to tell.)
I would certainly hope that FALSE is defined as 0.
D
Dave Hansen
FWIW, the interacting "good ideas" suggested by the coding standard
are:
1) putting the constant first in the comparison.
2) Always putting a comparision in a conditional.
3) Never comparing a value to TRUE.
None of these ideas is bad all by itself, and each actually has some
benefit. But the gestalt...
I would argue it is MUCH clearer. You can read it out loud and know
immediately what it means.
My personal preference is to omit comparison operators when testing
boolean flags ("if (is_complete)"). I've met with some resistence
with my various employers' coding standards.
Oh yes, the codebase here isn't completely incoherent.
Regards,
-=Dave
C
CBFalconer
Keith said:
More to the point, how do you read '='. I recommend 'gets'.
K
Keith Thompson
Dave Hansen said:
Ick. (My reaction is a personal one; others have good reasons for
liking this rule.)
No. Not all conditions are comparisons.
Agreed, but it doesn't go far enough.
Never compare a value to FALSE, because it's unnecessarily verbose.
Never compare a value to TRUE, because it's unnecessarily verbose,
*and* because it can yield incorrect results (since any non-zero value
is considered true).
Are you saying that if (is_complete != FALSE) is much better than
if (FALSE != is_complete)? If so, I disagree -- but again, that's
just my personal opinion.
[...]
My preference is stronger than that. If something is already a
condition, comparing it for equality or inequality to TRUE or FALSE,
to create a more complicated condition, is just nonsensical. I'll do
it only if I'm forced to, either by a stupid coding standard (I'm
lucky enough not to have to work under such a standard) or by a
limitation of the language I'm using. <OT>Such comparisons are
sometimes necessary in Bourne Shell scripts.</OT>
P
pete
Keith said:
I read "==" as "compares equal to".
(UINT_MAX == -1)
"UINT_MAX compares equal to -1"
R
Richard Heathfield
Dave Hansen said:
Likewise (albeit without the space).
Whenever I encounter problems with site coding standards, I simply lobby
to have the standards changed. A reasoned attack based on quotes from
ISO/IEC 9899 usually has the defence running for cover fairly soon.
Likewise (albeit without the space).
Whenever I encounter problems with site coding standards, I simply lobby
to have the standards changed. A reasoned attack based on quotes from
ISO/IEC 9899 usually has the defence running for cover fairly soon.
R
Richard Heathfield
CBFalconer said:
I never recommend 'gets', since it has no way of defending its buffer
against abuse, accidental or otherwise.
Instead, I recommend 'becomes' or 'takes the value'.
I never recommend 'gets', since it has no way of defending its buffer
against abuse, accidental or otherwise.
Instead, I recommend 'becomes' or 'takes the value'.
B
Bill Pursell
I started doing this about 3 or 4 months ago, and I'm
growing fond of it. I usually reserve the practice for
comparisons with null or function returns, eg
if( BUFSIZE != fread ...), and I think the readability
issue is a good thing. In other words, because it
is unnatural, it jars your eye and you are reminded that
the error check is happening. Also, it's easier
to pick out the constant. Compare:
while( BUFFER_SIZE == (read_count = fread( longish_buf_name, sizeof
*longish_buf_name, BUFFER_SIZE, ifp )) {
while( (read_count = fread( longish_buf_name, sizeof
*longish_buf_name, BUFFER_SIZE, ifp ) == BUFFER_SIZE ) {
I definitely prefer the first.
S
santosh
CBFalconer said:
I almost never read code aloud, even within my head, but when I do, I
tend to spell that as "is assigned."
D
Dave Hansen
But "gets" is evil. ;-)
I read "a=b" as "a equals b" or "set a equal to b" if I'm feeling
verbose.
I read "a==b" as "a equal-equal b". Works for me. I find it
analogous to read "a!=b" as "a not-equal b".
Regards,
-=Dave
S
stremler
be gin quoting Richard Heathfield said:
Yes, that is what I was asking.
Basically, "if you were explaining code to someone else, how would you
read (out) the statement"?
Reading it as "has the same value as" explains a lot, I think, as to why
you don't find an aesthetic difference, but others do. I may have to try
that for a bit and see if it makes a difference.
R
Racaille
you should seed the pseudo-random generator with srand() only *once*,
when the program begins (or periodically - but not every time you
call rand() - from a source of real randomness, like /dev/random,
etc).
- seeding every time as you do is like setting 'roll' to time(0)-13,
only slower
as for the difference between '=' and '==', you will probably grasp it
after 2 weeks of practice, without having recourse to 'if(0 == foo)'
or
'if((foo == 0))' self-mutilation, as some people suggested ...
P
pete
I read "==" as "compares equal to".
"UINT_MAX has the same value as -1",
doesn't sound right to me,
"UINT_MAX compares equal to -1" sounds OK.