|
This stuff drives me up the wall!!!
bool is_queue_empty(void)
{
if (queue_length==0)
{
return true;
}
else
{
return false;
}
}
Or this:
bool counter_zero = counter==0 ? true : false;
Or this:
if (isUDPSetup()==true)
{
if ((forceSend==false))
{
...
}
}
(Variable names have been changed to protect the guilty)
Or this *New one*:
void setNeedsUpdate(bool update)
{
if ((update==true))
NeedsUpdate=true;
else
NeedsUpdate=false;
}
modified 6-Dec-11 9:06am.
|
|
|
|
|
You are a lucky man if that's all that makes your life miserable. Some of this is awkward, especially the second example, but where exactly is the horrible part? What damage is done? Does it not work or are there possible side effects? Does it lead to worse code being generated by the compiler?
I think the first two just show a clumsy coding style, but no real harm comes from it. Except, of course, curling up your toenails when you have to read it.
Usually I do the last one myself. It is at least the same way you compare any other variable (if (x == 0), so why not if (flag == true)?) and I prefer to make it absolutely clear what I want to accomplish. The compiled code remains absolutely the same, no matter how you write it. That's why I see the last one more as a matter of preferences, but not as anything important.
And from the clouds a mighty voice spoke:
"Smile and be happy, for it could come worse!"
And I smiled and was happy
And it came worse.
|
|
|
|
|
Screw the compiler. It takes longer to read and understand, therefore it sucks.
|
|
|
|
|
And it obviously makes the reader scared of what else might come from that code who's developer can't understand even a booleans...
"To alcohol! The cause of, and solution to, all of life's problems" - Homer Simpson
|
|
|
|
|
i might be showing my age here but there used to be a readability test known as "the telephone test" (from Kerningham and Plauger) - Read your code to someone over the phone. If they can't understand it, try writing the code again. admittedly this has its problems but one of the upshots was that you should just name your booleans for the thing they test and then it reads well. also, comparing to "== true" or "== false" obviously breaks this readability test 
|
|
|
|
|
mostlyharmless1964 wrote: i might be showing my age here
Wow, never heard of it. Was it the time when the compilers were birds inside stone cases? 
"To alcohol! The cause of, and solution to, all of life's problems" - Homer Simpson
|
|
|
|
|
The harm comes entirely from maintainance, more code == more bugs or at least harder to spot them.
I apreciate your style preference on the last one, and the last thing I want is to start a style argument, but I am curious, would you also do this if you had two flags?:
if((flag1==true) && (flag2==true))
{
...
}
Because this guy does, and they get longer and longer because of all the ==true and ==falses, makes simple boolean expressions look very complicated.
|
|
|
|
|
Yes, I suppose this simply comes from the old C++ days where there was no boolean type. To avoid side effects or compiler specific behavior, I always explicitly specified what I was testing.
But I would write it like this:
if((flag1 == true) &&
(flag2 == true) &&
(flag3 == true))
{
...
}
Usually it does not look so uniform. If I really had so many different flags, I would think about using a flag word and testing all flags in one go.
And from the clouds a mighty voice spoke:
"Smile and be happy, for it could come worse!"
And I smiled and was happy
And it came worse.
|
|
|
|
|
Well this kind of code can be even more dangerous in C where you have #defined your true and false constants (dont' know if it's same in C++).
Now you can get the situation where potentially neither section 1 or 2 runs:
if(a==true)
{
}
if(a==false)
{
}
At least if you don't use the constants, it behaves as a boolean, here either section 1 or 2 is guaranteed to run.
if(a)
{
}
if(!a)
{
}
|
|
|
|
|
Fine. Now what if a is a (signed) integer and has a negative value? Or what if a is a pointer which is currently NULL? Without having defined any value for TRUE or FALSE and without knowing how NULL was defined somewhere deep in the libraries, how do you now know which code will be executed and which not? Even if NULL is usually defined as 0x00, you cannot expect this to be true for every compiler. And what can happen if you use another compiler?
int* a = NULL;
int b = -42;
if(a)
{
}
if(a == NULL)
{
}
if(b)
{
}
if(b < 0)
{
}
And from the clouds a mighty voice spoke:
"Smile and be happy, for it could come worse!"
And I smiled and was happy
And it came worse.
|
|
|
|
|
I am with you that if it's an integer or pointer do the code like you have described, it's fine code, I do prefer to do it this way. But you still arn't using defines for true and false, which is my original beef.
However any compiler that doesn't define zero as false and non-zero as true for boolean expressions is not a standard C compiler.
|
|
|
|
|
The simple answer: I would, for example, use the Win32 type BOOL. I can safely compare any variable of the type BOOL to the definitions of TRUE or FALSE and that is what I would do. Trying to compare any variable of another type with TRUE or FALSE would be asking for trouble. Also, I would not use other types to express boolean values, even if C/C++ allows this, so that there is never any need to compare them to TRUE or FALSE
BOOL b = TRUE;
int i = 1;
if(i == TRUE)
{
}
if(b)
{
}
if(b == 1)
{
}
if(b == i)
{
}
if(b == TRUE)
{
}
Coming back to managed languages where a boolean type exists: Here no other type can be used to express boolean
values, so explicitely comparing to true or false is not needed. I guess it's simply a habit I have carried over
without thinking much about it.
And from the clouds a mighty voice spoke:
"Smile and be happy, for it could come worse!"
And I smiled and was happy
And it came worse.
|
|
|
|
|
alanevans wrote: define zero as false
What size of zero? 
Even defining it as zero may be problematic down the line. One place I worked (which had to compile its code for 16-bit DOS, 32-bit Windows, and 64-bit OpenVMS used:
# define true (0==0)
And were therefore protected against issues of size, or whether zero was true or false, or even if some future compiler has an actual boolean type. That, in my opinion, is the only way to go.
|
|
|
|
|
Yep. I used to do that myself.
#define true (1==1)
#define false (1==0) If your language does not define values, it's the only sensible way to do it.
Ideological Purity is no substitute for being able to stick your thumb down a pipe to stop the water
|
|
|
|
|
Surely a zero is the same size whatever the width of numbers? For negative values you have to be careful but zero and small positive integers should work for everywhere.
That's quite a neat way of defining true, except that it presumably results in an extra comparison taking place in every test where you use it.
|
|
|
|
|
It's not the size, it's how you use it
|
|
|
|
|
Simple, where the value isn't boolean or a pointer, don't use that technique to test for 0.
In C, I always used "if (c == 0)" for integer values, "if (c)" for booleans. Its the only safe way to do it, as there's no safe value for "true" for an integer.
e.g. in bitwise arithmetic, commonly a bitfield may be tested for one or more of a number of bits set using a mask. The result may be 0 (none set) or some non-zero value (where 1 or more is set). In this case, the C behaviour works as expected, and indeed it was designed for exactly this kind of usage.
|
|
|
|
|
Rob Grainger wrote: e.g. in bitwise arithmetic, commonly a bitfield may be tested for one or more of
a number of bits set using a mask. The result may be 0 (none set) or some
non-zero value (where 1 or more is set). In this case, the C behaviour works as
expected, and indeed it was designed for exactly this kind of usage.
Works as expected? What if 'one or more flag set' is still too weak a condition? What if you need to know wether or not all flags in the mask are set? We really have three cases here and using the C behavior here may actually be suboptimal:
LONG lResult = lFlagWord & lMask;
if(lResult == 0)
{
}
else if(lResult == lMask)
{
}
else
{
}
And from the clouds a mighty voice spoke:
"Smile and be happy, for it could come worse!"
And I smiled and was happy
And it came worse.
|
|
|
|
|
Hey, I went and looked this up, the standard states explicitly that
"In both forms, the first substatement is executed if the expression compares unequal to 0."
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1548.pdf[^] page 147
That is, negative numbers are defined by standard to be true for conditional expressions.
|
|
|
|
|
(edit: I posted this as a reply to a message that is now now longer there, oh well)
I do not write out the boolean, but I do write each condition on a new line.
In addition to that, I start the new line with the operator, this way, it is very easy to see at the beginning of the line that it is a continuation of the previous line, and what the operation is:
if( flag1
&& (someOtherFlagThatWillSqrewWithTheLayout == MagicNumbers.Ten)
&& (flag3 == somethingElseCompletely))
{
...
}
I use this style with anything that will make a line of code too long:
var firstChildRow= SomeTypedDataSetWithSillyLongNameThatFillsTheEntireCodeWindow.Tables[0].ChildRelations[0].ChildTable.Rows[0];
var firstChildRow= SomeTypedDataSetWithSillyLongNameThatFillsTheEntireCodeWindow
.Tables[0]
.ChildRelations[0]
.ChildTable
.Rows[0];
|
|
|
|
|
I came from the same dark ages and indeed untill some time ago i also had the tendency to check the boolean value. Particularly the BOOL was a nasty one as you could (with good sense) only check that to FALSE. One other 'trick' i got used to apply was swapping the variable and the value
E.g.
if(FALSE != flag)
{
Logically this seems a bit odd but then again it did protect me against typo's like:
if( flag = FALSE)
{
Today this will generate a compiler warning but that has not always been the case and if you have a special vendor type compiler; you may still face the same.
Why check on FALSE? Simple; that was defined (as 0), any one could set the BOOL to TRUE, 1, 2 etc.
Don't you love the compilers of today? Or better yet, those of tomorrow?
Cheers, AT
Cogito ergo sum
|
|
|
|
|
CDP1802 wrote: why not if (flag == true)?
Indeed, I prefer that when writing in C.
One thing that drives me nuts with C is reading things like:
char* s = ...
if ( s ) ...
|
|
|
|
|
Me too, but then there are the 'noobs' who just know languages like C# or Java and make up smart coding rules which only work as long as they don't ever have to leave their comfortable little world. At times I still have to use some old school methods and have no choice but to ditch object orientation or *gasp* use branching instructions (that's something like GOTO). Our 'modern' friends would not get very far with their 'must do this' and 'don't do that' rules.
And from the clouds a mighty voice spoke:
"Smile and be happy, for it could come worse!"
And I smiled and was happy
And it came worse.
|
|
|
|
|
OP used C#. It might possibly look like it could be an other language, but the pre tag has lang="cs".
Comparing bools with constants is nonsensical in C#.
Comparing bools with constants in x86 assembly makes even less sense and takes special effort just to do it wrong.
|
|
|
|
|
harold aptroot wrote: Comparing bools with constants is nonsensical in C#.
And it's in no way harmful. But it is consistent with other comparisons.
harold aptroot wrote: Comparing bools with constants in x86 assembly makes even less sense and takes
special effort just to do it wrong.
That I see differently. Defining a boolean type and declaring adequate constants to use with it eliminates most of the problems. Of course only if you use your boolean type for boolean values and nothing else. Unfortunately there is no way to limit your boolean type to just 'true' and 'false' and there is also no mechanism to enforce the use of your boolean type. As always, this is the point where only discipline helps.
And let's not forget this little detail:
int x = -5;
if(x)
{
}
else
{
}
And from the clouds a mighty voice spoke:
"Smile and be happy, for it could come worse!"
And I smiled and was happy
And it came worse.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
