5 ways to give a name to your booleans

Booleans are either true or false. And sometimes, they mean more than just that : they are options in a method call. There, it is difficult to differentiate them, without a good dose of documentation and self-trust. Thus, you need 5 ways to give a name to your booleans.

<?php
    // what does this do ? 
    var_dump($variable, true); 

    // what does this do ? 
    print_r($variable, true); 
?>

Readability suffers with booleans as arguments : they have a value but they don’t convey any meaning. Here are five syntaxes to makes they more readable.

Make them a constant

First solution is to give the booleans a name : with a constant. Either a global constant, or a class one, depending on the situation (and more on that next section). It is an opportunity to display the meaning of the boolean.

<?php
  const STRICT = true;
  const LOOSE  = false;
  
    $variableDisplay = in_array($needle, $haystack, STRICT); 
?>

PHP provides such constants for integers, such as COUNT_NORMAL and COUNT_RECURSIVE. Note how there is little need for documentation to find which native function makes use of them.

Sadly, PHP doesn’t provide constants for the booleans, as they would be repeats. So they need to be added manually.

Turn then into an enumeration

Boolean may easily turned into objects (sic), simply by replacing them with a related enumeration. An enumeration provides a set of the cases : in this situation, two cases are enough.

<?php
  enum Comparison {
    case STRICT;
    case LOOSE;
  }
  
  function foo(bool $comparison) {} 
  function goo(Comparison $comparison) {} 

  foo(true);
  goo(Comparison::STRICT);

?>

Enumerations provide a type for the parameters. In fact, the original booleans are now turned into as many sets of enumerations as arguments : there is no more possible confusion of true in_array() comparison severity and print_r() display option.

Enumeration may also accomodate more cases later : they make a good base for future evolutions. Of course, PHP 8.2 or later is needed for that.

Use the named parameters

Since PHP 8.0, it is possible to provide the arguments with their name, rather than their position. The name is written as a label, before the value itself. It make the call quite clear. These are the named parameters.

<?php
    $variableDisplay = in_array($needle, $haystack, strict: true); 
?>

Use a dummy assignation

Before PHP 8.0, there was no named parameters, but there were iffectations : this is an assignation, used as a condition. The trick is to use a readable name for the assignation.

<?php
    $variableDisplay = in_array($needle, $haystack, $strict = true); 
?>

That way, the arguments are still positional : they must be in the same order as in the method signature. The variable name should be the same as the parameter, but, unlike with named parameters, it is not necessary anymore.

One caveat to mention : since this sets a local variable, be aware not to overwrite a previous variable, or set an upcoming one.

Comments

Comments may be the last alternative : their role is to comment the code, and provide context. And this is an actual situation.

<?php
    $variableDisplay = in_array($needle, $haystack, /* strict */ true); 
?>

One may find them a bit ugly, and possibly less convenient than the last options.

Comments also may drift from the actual meaning, and will not warn of any mis-usage : this is static documentation after all.

Meaning and value are distinct

Booleans are literals with a definite value: they need to be given a meaning when they are used in the code. All the solutions above provide a mean to replace the literal values with human readable messages. In the end, booleans should only end up in constant definitions, and calls to PHP native functions.

Interestingly, integers sometimes play the same role of options, as booleans. When they do, such integers could be updated with the same solutions presented here. Their larger size leads to flags, that combines multiples options. The rest of time, when the integers are providing a value on their own, they should be left intact.

Differentiating between the multiple usages of boolean or integer within an application, is actually a classic coding quest : the infamous magic number code smell.