|
And yet that style of testing for non-null is the standard in, for example, JavaScript. (Personally I have no problem with it in C either, for pointer or unsigned types ... with signed values it's bad because as pointed out someone could potentially switch negative values' interpretation out from under you.)
When comparing against something which is (semantically or definitively, depending on your language) a boolean, though, there's absolutely no reason to make the reader parse more text before he can understand your statement. Adding the ' == true' provides zero clarification value, as anyone who vaguely knows the language knows that if tests check for a true value. In your example here, adding the ' != NULL' does provide a little clarification, so it's pretty much a value-neutral stylistic choice to add it or not.
(Someone might suggest that NULL could evaluate to true, but anyone who makes that #define is far more culpable for any confusion than the person who writes the check you put here, and in any professional context that won't be the case.)
|
|
|
|
|
BobJanova wrote: Adding the ' == true' provides zero clarification value
Exactly! Not only that, it also adds the potential for a catastrophic typo: =true instead of ==true.
I'd even go so far as to include comparisons to user-defined symbols that represent boolean states, such as TRUE and FALSE: if if(x) is not equivalent to if(x==TRUE), then the definitions are wrong, since they do not adhere to the rules of boolean logic! In that case not the comparison needs to be 'fixed', but the definitions!
|
|
|
|
|
Don't see why. The C language explicitly defines that comparison to work for null vs. non-null values, with the expected behaviour.
|
|
|
|
|
That in combination with the inabiliy to properly initialize a variable has ruined more than one day...
Cheers, AT
Cogito ergo sum
|
|
|
|
|
CDP1802 wrote: t is at least the same way you compare any other variable (if (x == 0), so why
not if (flag == true)?
My reasoning is you could take any boolean expression, and instead of writing
if (X) you could write
if (X==true) to make it really clear. But you could then also write
if ((X==true)==true) to make it really really clear.
So I'm thinking let's drop all implied trailing "==true"'s in a mental tail call optimization. 
|
|
|
|
|
And I think your reasoning would be wrong. It IS more clear to write if (X==true). Just because you don't like it does not mean it is not more clear, especially to junior programmers. I am the senior lead and I instruct ALL of our programmers under me to write if (X==true). It doesn't cost the compiler anything and it makes it understandable by even the junior most person quickly. It is all about proper maintenance and thinking about the coder behind you instead of just yourself.
X is a variable so comparing it like another variable is both consistent and readable.
|
|
|
|
|
This is, at best, a matter of opinion. For me it is less clear to write if(x == true) because I have to read twice as much text to get the meaning &dnash; just as it's unclear to give a method a 300 character name. I have never met anyone who is confused by if(booleanVariable) and if they are then they shouldn't be programming until they learn the language they're using – if they have trouble reading that then do you really want them poking around your pointer code, or reflection in C#, or constructor injection frameworks, or any of the other million things any real world app has that are far more confusing?
Readability is all about having a single, clear, unambiguous meaning for a statement as quickly as possible. if(x) and if(!x) are short, clear and obviously different from each other (as long as you're using a font where ! is more than 2 pixels wide, heh). if(x == true) adds nothing, is easier to mix up with closely related but different statements (if(x = true) or if(x == True) or if(x == "true") etc) and doesn't immediately show that x is a boolean or castable to one until you read the whole thing.
You are on your way to becoming one of the micromanaging senior leads who appear on The Daily WTF issuing that kind of order based on your personal opinion of readability.
|
|
|
|
|
Why do boolean variables exist? To store and retrieve boolean expressions (TRUTH values). They were invented SO THAT we can write code like
if (X) otherwise we could just as well remove the boolean type and work with integer flags like
if (X==1) This was one of the issues people had with C. No proper boolean type. But now we have a proper boolean type so don't reduce it to a "flag value" that needs to be compared to something to find the truth. It holds the truth all on its own. That's its job.
|
|
|
|
|
Believe it or not, but my high school teacher recommended doing this "because it's more clear". I was the only one ignoring that and only got flak for it.
|
|
|
|
|
Perhaps that is why he was a high school teacher.
|
|
|
|
|
Which just show that there are 10 types of people in the world ...
|
|
|
|
|
I know that 0 is false (or FALSE) and anything else is true (or TRUE)
disappointed to read through the comments 
... old C++ days ...
since C++ defines "true" and "false" because defines the "bool" type
the trick comes around when the main function must return 0 if everything is OK 
---------
Antonio
|
|
|
|
|
PinballWizard wrote: the main function must return 0 if everything is OK
That's why zero should mean true. 
|
|
|
|
|
> if (isUDPSetup()==true)
You won't believe, but stupid hindu who wrote WPF (and .NET probably) follow logic like this! Look at ShowDialog() function - at WinForms time it was simple 'bool ShowDialog()' and code looked perfect: 'if (ShowDialog()) blah..'. Now they introduce... "bool?"!!! And code MUST look like "if (ShowDialog() == true) then...". You see that?! Really stupid....
|
|
|
|
|
Wouldn't this be more run-time efficient, as the value of update can be cached in a register ?
void setNeedsUpdate(bool update)
{
if (update == true)
{
NeedsUpdate= update;
}
else
{
NeedsUpdate= update;
}
}
;->
|
|
|
|
|
Or more straightforward:
void setNeedsUpdate(bool update)
{
NeedsUpdate = update;
}
Less confusing, and same behavior.
|
|
|
|
|
What about this:
void setNeedsUpdate(bool update)
{
if (update == (update == update))
{
NeedsUpdate= update;
}
else if (update == (update != update))
{
NeedsUpdate= update;
}
else
{
NeedsUpdate= update;
}
}
it has the advantage of using no constant at all and cleanly handles the case where update is not a boolean value.
I have added enlightening comments.
modified 2-Jan-12 5:06am.
|
|
|
|
|
The horrors I've seen:
void setVisible(bool isVisible)
{
if(isVisible.ToString().ToLower() == "true")
{
this.Visible = true;
}
if(isVisible.ToString().ToLower() == "false")
{
this.Visible = false;
}
}
|
|
|
|
|
You're making this up, aren't you? 
|
|
|
|
|
I wish I was making this up. 
Although it's good for a laugh (then a cry) when we go in to fix a bug in his old modules.
|
|
|
|
|
I hate this code too. Maybe in C you can do this but in C# it is a travesty. What I do is create self-documenting booleans so that you write code like this:
if (DoorIsOpen)
{
}
else
{
}
I feel that this eliminates the need for any of the crap above. It is true that the compiler doesn't care but just remember the the point of code is so humans can understand it. If we only cared about the computer understanding it, we would all be typing 1s and 0s. Write code so that those who come after you can read it without being distracted by how horrible it is.
"I don't believe it."
"That is why you fail." -- Empire Strikes Back
Shameless blog plug - www.geekswithblogs.net/jboyer
|
|
|
|
|
Let's see...
The first example I don't like - not for the if statement, but for the premature returns! Personally, I'd make it a one-liner, but I don't consider it all that horrible apart from the returns.
The second ... well you could argue it's slightly more readable for inexperienced programmers, but if that is your purpose then you should write an if/else statement, not use ?:.
The next is a double horror for comparing to boolean constants and unnecessary nesting, but I'd forgive the nesting for the off-chance of later maintenance introducing additional statements that depend on only the first condition.
The last ... I suppose if you need to be able to run your code through really old C compilers that don't have their own built-in definitions of bool, true and false, then it makes sense not to assign one boolean variable blindly to another, but instead make an if/else statement to catch the case where the argument is neither true nor false. But even then, ==true is horrible.
So, in short, all of the examples are indeed bad style, IMHO, but I agree with the others that no harm is done, except maybe a minor hit in maintenance effort for posting it in the Hall of Shame. None of this will cause inefficiency either, since compilers are smart enough to produce efficient code even from that kind of code.
|
|
|
|
|
They were probable taught to program by some CS grad student who'd never done much significant real-world coding. That's right along the lines of the kinds of stupidity my teachers would teach us when I was an undergrad. Like everybody else, I picked up the stupidity too.. which lasted until I saw the other way and had to debug code to a schedule that was broken by such nonsense.
I still do the compare to NULL sometimes, but I believe the C standard now defines NULL pointers as a false boolean value, so it is redundant and I'm trying to retrain away from it. Besides, boost smart pointers, which we use a lot in our code, have an override to generate a bool result for just such kinds of pointer checks and make comparing the raw pointer to NULL harder.
We can program with only 1's, but if all you've got are zeros, you've got nothing.
|
|
|
|
|
Personally, I don't promote the C rule that implicitly turns an expression to boolean based on zeroness, whatever the type. Because even though perfectly legal it looks like a quick & dirty shorthand to spare typing a comparison; and it can overload an identifier with two meanings, that of the numerical value (or address) and that of a condition, as if the variable had two data types.
What would you think of this (fiddled) snippet:
int NoRetries; NoRetries= SendMessage();
if (NoRetries)
{
}
as opposed to
if (NoRetries > 0)
{
}
C was lacking a boolean type in the old days, in my opinion a design flaw. That made the aforementioned rule perfectly relevant. I prefer making the booleans explicit and highlighted.
In a moderatly pedantic style, this would give us
bool Retried= NoRetries > 0;
if (Retried)
{
}
|
|
|
|
|
I absolutely agree with you and consider using the a-zero-int-value-is-a-bool-false feature of C/C++ to be sloppy. Valid, but sloppy. I consider it sloppy because 0 is a meaningful (and highly useful) value for an int.
However, with pointers, NULL is a meaningful value that indicates the pointer points to nothing, all other values are considered valid pointers. Using a pointer like a bool and checking if it is explicitly NULL are the same -- they are both asking if it points to anything. There is no other possible semantic interpretation.
Writing code that omits an explicit comparison to NULL is also more easier to upgrade if the pointer is switched to one of the boost smart pointer classes, something we've done a fair amount of over the years. Not that the compiler doesn't catch the now-invalid comparison, but then you have to touch all that code just to get the same semantic meaning.
We can program with only 1's, but if all you've got are zeros, you've got nothing.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
