Code Style Terror II — The Value of the Truth

Nuno Grilo Pinheiro
Code Style Terror
Published in
4 min readMay 12, 2016
This is false in Java

Booleans are the most important concept in computer science. Whole processors are made based only on Boolean Algebra through logic gates, and conditional statements are what enable us to create logic in high level programming languages.

Since they are fundamental to programming, we usually master them in the early learning phases of programming , turning these weird zero and one operations into a simple and natural reasoning. But as every simple technique, it can be cryptic if used in excess or in the wrong contexts.

Boolean equals True

I remember once listening to a Professor criticizing a piece of code because, instead of returning a Boolean variable, returned the expression:

return booleanVariable == True

Even a programming student can see that this expression has the same result as the booleanVariable itself. In fact, knowing this is so easy, that the compiler/interpreter will probably ignore the equals operator and just return the variable.

But lets ignore code performance and focus on readability. You are reading a piece of code to check if a bill was paid, in a language where you do not need to declare your function and variable types, such as Python or Scala, and you read one of the two following return lines:

1)return paid 2)return paid == true

Without more context, from which code line can you understand better the return type of the function? The sample 1 is enough to achieve the right value, but the second case gives more information to the reader by saying that paid is a Boolean, the function returns a Boolean, and the function returns true if the variable paid is true.

Of course I do not want everybody to start writing code like this since most of the time it is a simple variable naming problem. If you prepend “is” or “was” to your variable names the code will probably be perfect. Just change the variable in the presented code to “wasPaid” and it is fixed.

The emptiness will haunt you

I am mainly a Java programmer, and as a Java programmer I like my if statements to be based on Booleans. But sometimes I need to go JavaScript, and lately I am spending lots of time programming in Python. In these languages any value can be used inside if statements and any value ,or absence of a value, has a corresponding Boolean. An heuristic I use to understand them is the “emptiness” of the value. “Empty” values are false, non-empty values are true. For instance in Python:

  • 0 (zero) is an empty value (false). Any other number is non-empty.
  • An empty list… is empty (false). Non-empty list, not false. The same for dictionaries.

This feature is so rooted in JavaScript language, that is usually used to conditionally initialize variables in an idiomatic way. By using short-circuit evaluation, the following JavaScript sample 1 is equivalent to the 2nd example:

1)var a = a || {}2)if(!a){  a = {}}

The fact that we can use any variable in if statements, and according to the last section using “== True” is redundant and usually not done, this leads to curious code:

if(paid):  print “already processed”else:  processPayment()

In this code, we do not know if paid is the “amount paid” or the fact that it “was paid”. Adding a simple “!=0” or “==True” will add some more semantic to the code.

Boolean Algebra != Cool

Boolean algebra in programming languages feels really natural, we have the and, or, xor and not operators and we can easily compose expressions that can solve complex logic.

The problem with this composition is its reader non-friendliness. For example, I once wrote some code that checked if a contact needed to be validated. Web pages didn’t need validation, and phone numbers only needed validation based on a configuration variable:

def requiresValidation():
return !(isWebAddress ||
((isMobilePhone || isPhone) && !requiresPhonesValidation));

The logic is easy to read, but based on this code ,and considering that a comment is not present, you cannot easily transpose the requirements from the code. Based on the code it is hard to get the human answer to “When does the contact needs validation?”

Simply abstracting parts of the logic into smaller pieces would lead to a better human readable code.

def requiresValidation():toValidatePhone = ((isMobilePhone || isPhone) &&     
!requiresPhonesValidation)
return !(isWebAddress || toValidatePhone);

Of course, this is subjective, I consider the previous refactor to improve code reading, since I will probably focus on the last line of the method when skimming through the code, but other people may consider that the “toValidatePhone” assignment could be further refactored.

What About You?

Have you ever seen a Boolean expression so hard to understand that even Pinocchio's nose would not know if it was supposed to grow or not?

youLiked && please(heart || comment)

If you liked this post, please heart or comment :)

--

--