Boolean complexity hurts readability of your LabVIEW code, just like it hurts the readability of the title of this post. I’m going to illustrate some design choices you can make that improve readability without changing the functionality of your code.

Avoid Negative Comparisons

As in life, it’s better to be positive than negative. When looking at this block diagram

Does this code give the same result as the other examples?

the reader must contend with a double negative to determine whether the false sub-diagram is executed for a particular value of the input. Making the positive comparison instead

is a small change, but never requires the reader to contend with the double negative. When using While and For loops with a conditional terminal, you can sometimes eliminate a negative comparison by switching between the Stop and the Continue versions of the terminal.

Avoid Comparisons

Since LabVIEW “syntax” for case structures is equally easy for Boolean and integer inputs, our code is even simpler to read if we eliminate the comparison altogether.

Select Case or Select for Different Cases

Eliminating the comparison isn’t the only way to improve our code readability above. In some circumstances, it’s better to leave the comparison in place and use a Select function instead.

This makes all our code visible at once. How do you decide when to use Select functions instead of case structures? Use Select when a) there are only two cases b) it’s easy to calculate the logic for the two cases (you don’t want to leverage the case structure’s range features) c) you only have one result and d) it takes negligible time and block diagram space to calculate both results.

Simplify Using Compound Arithmetic

If your Boolean logic contains many nodes, especially if they cascade through multiple layers, it can be very hard to understand what the intent is, and also hard to get the code itself right.

Here, it’s often best to use the Compound Arithmetic node to flatten and simplify the logic.

This example shows an important feature of the Compound Arithmetic node, the ability to invert each of its inputs. You can also invert it’s output, which is sometimes useful but makes a negative comparison.

Conclusion

Boolean complexity is sometimes necessary, but by avoiding it when you can, you will improve the readability of your code.