The Weird and The Wonderful

int*   a = NULL;
int    b = -42;


if(a)
{
    // We should not need to know how NULL is defined and therefore can never know wether
    // or not this code block will ever be entered
}

if(a == NULL)
{
    // Now we explicitly compared with NULL and it is clear when this code will be executed
}

if(b)
{
    // Negative values are undefined and it is up to the compiler wether a negative value is
    // seen as 'true' or as 'false'
}

if(b < 0)
{
    // Explicitly testing the variable again removes all uncertainties
}

BOOL b = TRUE;
int i = 1;

if(i == TRUE)
{
    // TRUE may be defined in numerous ways, so this is likely not to work
    // I would simply not use an int (or other types) to express boolean values.
}

if(b)
{
    // It would be logical to assume that this works, but who knows how TRUE has
    // really been defined. In any case, we should not have to know and that
    // is why I avoid it.
}

if(b == 1)
{
    // TRUE (the value of b) may be defined in numerous ways, so this is likely not to work
}

if(b == i)
{
    // Very bad. Even if the definition of BOOL is based on int, it's unsafe to assume that this is so. And again
    // we should not have to care about how TRUE or FALSE are defined.
}

if(b == TRUE)
{
    // No problem here. Explicitly comparing a BOOL variable with TRUE or FALSE seems to be the only safe way.
}

alanevans wrote:

define zero as false

#define true (1==1)
#define false (1==0)

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.

LONG lResult = lFlagWord & lMask;
if(lResult == 0)
{
    // no flags in the mask are set
}
else if(lResult == lMask)
{
    // all flags in the mask are set
}
else
{
    // only some of the flags in the mask are set
}

if( flag1
    && (someOtherFlagThatWillSqrewWithTheLayout == MagicNumbers.Ten) 
    && (flag3 == somethingElseCompletely))
{
  ...
}

//Contrived Deep Nesting, line too long
var firstChildRow= SomeTypedDataSetWithSillyLongNameThatFillsTheEntireCodeWindow.Tables[0].ChildRelations[0].ChildTable.Rows[0];
//Broken up for readability. Note that I start with the 'dot'.
var firstChildRow= SomeTypedDataSetWithSillyLongNameThatFillsTheEntireCodeWindow
                       .Tables[0]
                       .ChildRelations[0]
                       .ChildTable
                       .Rows[0];

 if(FALSE != flag)
{

 if( flag = FALSE)
{

CDP1802 wrote:

why not if (flag == true)?

char* s = ...

if ( s ) ...

harold aptroot wrote:

Comparing bools with constants is nonsensical in C#.

harold aptroot wrote:

Comparing bools with constants in x86 assembly makes even less sense and takes
special effort just to do it wrong.

int x = -5;

if(x)
{
    // will this block be executed?
}
else
{
    // or this one?
}

mov eax,0
setz al
cmp eax,someconstant

harold aptroot wrote:

Yes but that's C, not x86 assembly.

BobJanova wrote:

Adding the ' == true' provides zero clarification value

CDP1802 wrote:

t is at least the same way you compare any other variable (if (x == 0), so why
not if (flag == true)?

if (X)

if (X==true)

if ((X==true)==true)