Proposal: Boolean expression style guidelines

[KotzaBoss]

Abstract

Propose to set more strict guidlines for boolean expressions, favoring verbosity to brevity with too compact boolean syntax.

Rationale

Ignoring functions that return complex objects that often provide their equality methods, many Qt functions return an enum which can be checked for equality. That is a great way to ensure the code both works and is readable.

auto ret = mysteryFunc();
if(ret == Result::Ok) { ... }

However many more functions return a boolean that can be used with a very compact syntax when checking its false value. And as we know...

Programmers love brevity.
-- Brandon Rhodes, Python guru

That syntax lead me to an interesting predicament when checking if a pointer is null or not. I will exagerate the issue to prove my point.

if(!selected) { ... }

In this experimental case what does selected mean? Selected or not, so bool? or the selected pointer is null? or perhaps selected represents the column so 0? Of course one can say that better naming like selectedItem or isSelected alleviates this issue but im inclined to not leave it up for interpretation.

Details

The primary types that may lead to confusion are numerical values, bool and pointers when checked for their 0/false/nullptr values. The problem lies that one can make a brief expression which may end up causing confusion in the future.

if(!value) ...  // what might you be...

In order to be verbose these types should be explicitelly compared

• Numeric

  if(x == 0) ...  // Explicit
  if(x != 0) ...  // Explicit
  if(x == some_value) ...

• Bool

  if(b == true) ...
  if(b == false) ...

• Enum

  if(e == Enum::someValue) ...  // Even for pure enums

• Pointers

  if(p == nullptr) ...
  if(p != nullptr) ...

Boolean Edge Case

The above guidelines can be altered for bool so that, assuming they are strictly followed, can allow the brief if(!value) syntax exclusively for them. That way brevity is used conventionally only for them while numeric values stay explicit.

bool b = false;
int i = 0;

if(!b) ...  // ok
if(!i) ...  // not ok

[fiffty-50]

You're making a very valid point!

I don't see the issue popping up so easily for enums since they are readily distinguishable by their unique syntax, but I completely agree with the issue you are lining out, especially for numerics and pointers.

I think a 'mandatory verbosity' for those cases would be a sensible guideline!

For bools (only) I would allow the brief notation as an acceptable notation - as you laid out, brevity is also a good thing if it does not create ambiguities or create potential issues!

Thank you very much for bringing this up!

[KotzaBoss]

I will be putting it to use from the following commits

[fiffty-50]

this is now also included in the coding style guidelines!