To Be or NOT To Be

I’m probably getting into quasi-religious questions here, but I’ve been reading someone elses code in an OPC (Other Peoples Code) project and they use a lot of statements like this:

If Not aBooleanValue then
   //do something here

I find this harder to read and much prefer:

If aBooleanValue = false then
   //do something here

I understand why people want to use the former but to me it reads backwards.  I have to flip the value in my mind before the variable and then keep that in mind for the eventual comparison later.

And don’t get me going on people that do things like this:

If Not (SomeFunction > 0) then

//do something here

To me, that’s just being too lazy to correct your code.  What should be explicitly clear is now not so clear (granted, this is a super easy example but you get my point).  I like to code for explicitness which means it’s easier to read (by me or someone else) weeks, months, or years from now.

I’m lazy.  I freely admit this.  I prefer to see the test values explicitly called out.  So something like this:

If aBooleanOne = True and aBooleanTwo = False and aBooleanThree = True then
   //do something here

is better than:

If aBooleanOne and Not aBooleanTwo and aBooleanThree then
   //do something here

For every ‘rule’ of course there’s an exception.  For simple boolean comparisons where I am checking for true I tend to write:

if aBooleanValue then
   //do something here

The True check is explicit and there’s only one variable to compare.  As soon as I use a second variable I will change it to be more explicit.

It’s such a little thing but when reading code one seems much easier than the other.  Or perhaps it’s just my OCD shining through.

What do you think?  Am I being overly critical or do you have similar beliefs?

11 thoughts on “To Be or NOT To Be

  1. Good tip, Bob. Something I’ll consider.

    Another case is when comparing to Nil. I prefer Is to = since the latter will trigger an object’s Operator_Compare if it has one, but don’t want to end up with code like this:

    If Not ( o1 Is Nil ) And Not ( o2 Is Nil ) Then

    Instead, I use IsA to get the same effect with readability:

    If o1 IsA Object And o2 IsA Object Then…

    • Good point. I wasn’t even considering the Is, and IsA, operators.

      The other thing I tend to do in Xojo is use all caps for the OR and AND.

      If o1 IsA Object AND (o2 IsA Object OR o3 IsA Object) then

      Between the default color used by the IDE and the all caps it separates the comparisons nicely, IMO.

  2. > If Not aBooleanValue then

    I don’t particularly like the NOT coming first in such comparisons, I’d rather write

    If aBooleanValue then


    End if

    I also try to be consistent and have the True condition first, the False condition second. It makes it easier to follow code because the structure then is familiar.

    • Believe it or not, I had someone request I change ARGen to use NOT instead of the explicit = false comparison. I thought it was pretty bold to even ask for such a thing.

    • I tend to make the condition such that I’m not writing deeply nested if then else structures

      if keepGoing = false then
      end if

      instead of

      if keepGoing then
      // a lot more code possibly with many more nested if’s

      end if

      the code I really want to run is , or could be, buried deeply in an if then else

      And that makes for not great readability

      but then I also tend to use a lot of early returns where some are more religious about “one entry one exit”

      • The ‘one entry, one exit’ is a completely different topic. But I do tend to agree with you to get out of a method as early as possible. With small methods this is no big deal but with 800 line methods (yes, I’m dealing with a lot of those in an OPC project) I end up having to scroll back up to the top just to remember what the condition was.

  3. I used to think using “boolVal = false” rather than “not boolVal” to be a beginner way to code. But seeing as how you do the “rookie” way then I guess maybe that’s not why people do it. 😉

    I do agree this:

    If aBooleanOne and Not aBooleanTwo and aBooleanThree then

    …is harder to read, but I still wouldn’t use = true/false in that case, I’d just make sure all the trues were together and all the falses were together, so:

    If aBooleanOne and aBooleanThree and Not aBooleanTwo then


  4. I generally like to be explicit. So I find this to be most preferable:

    If (aBooleanOne = True) Then

    Notice I use parenthesis around the condition. This is a throwback to C style languages where you might see:

    if (!aBooleanOne) {


    if (aBooleanOne = false) {


    I think a blend of the styles keeps it nice and readable.

  5. To be honest I’m so used to thinking “If aBooleanOne and Not aBooleanTwo” that I think I prefer it, however when evaluating an expression I always try to make a positive test rather than negative otherwise it messes with my head and in that direction lies bugs. 🙂

  6. I think it depends upon whether or not you enjoyed boolean algebra. Simple example:
    not A OR not B can be shortened to not(A AND B).
    This is much more difficult to visualise if you write
    A = false OR B = false which would shorten to (A = true AND B = true) = false
    The latter is kind of ugly.
    Beauty is in the eye of the beholder.

    • Sure. There are always exceptions to every rule.

      I spent many years doing boolean logic with PLC’s in manufacturing environments. But, PLC programming is also a visual language (at least when I was doing it in the dark ages) so it didn’t bug me nearly as much in that sense. Now, I code for ease of understanding five years from now when a client wants me to redo it.

Comments are closed.