Every developer encounters situations on a day to day basis where he has to write a code that flows based on some condition, and every condition eventually resolves to a Boolean. When conditions become complex enough to be part of flow control constructs like ifs..whiles..whens we tend to extract them into a method with meaningful name which usually takes the form of isXYZ where XYZ is the most logical name for the condition.
When I as a developer come across a method, that looks like isXYZ I intuitively assume that this method returns true if XYZ is true. Here XYZ should come as close to business as possible, examples being isAccountActive, isTokenValid, isUserEligible.
One more way of writing these functions is to return true when XYZ is false, which results in something like this : isNotXYZ, examples of such functions would be: isAccountInactive, isTokenInvalid or isUserInEligible. If we think about it, these methods could easily replace any isXYZ method, for example an If block that tests isUserEligible can easily accommodate isUserInEligible with a simple negation operator.
One can simply assume this is a harmless change(while it really is harmless, if we talk about code performance and correctness). But if we think about extensibility and reuse, imagine a case where I want to use isUserInEligible in a situation where I want to execute a block of code only if user is eligible, I would end up writing something like this:
!isUserInEligible
Whaaaaat??? Negation of Negation??
While this is equally correct, it is for me(and for a few other devs), subjectively much harder to read. More often than not, boolean conditions are a credible source of introducing a bug, and I would rather opt for a readable method name than get confused over silly conditions.
So, in conclusion, Boolean methods should look on the positive side of life —should have names that express if some condition is true, rather than expressing if some condition is ‘not’ true. In short the Boolean methods must be Optimistic.
– Chinmay
