Code Better: Booleans instead of Comments

There are lots of small tricks a programmer learns over time. With this post, I’m starting a little column called Code Better in which I’ll share some of my own tricks! If you want to show off some useful tricks of your own, I’d be happy to publish them here, too :)

The first trick is a simple technique to make complicated if statements more readable. Let’s take a look at this beast:

// Only access the height field if the position is within
if(
  (x >= 0) && (y >= 0) &&
  (x < this.heightField.Width) &&
  (y < this.heightField.Length)
) {
  return this.heightField[x, y];
} else { // Position is outside the height field
  return 0.0f;
}

The code isn’t unreadable per se, but it takes more than a glance to understand what’s going on. The comments help, but there’s a more elegant way that makes those comments entirely redundant:

bool isInsideHeightField =
  (x >= 0) &&
  (y >= 0) &&
  (x < this.heightField.Width) &&
  (y < this.heightField.Length);

if(isInsideHeightField) {
  return this.heightField[x, y];
} else {
  return 0.0f;
}

The beauty in this is that the first thing you see is bool isInsideHeightField, prominently positioned at one indent less than the conditions. Your brain registers the purpose of that block of code before it encounters the actual code.

The if below is also much more obvious. If the position is inside the height field, look up the value in the height field, otherwise return zero. Almost like reading english.

Finally, this level of obviousness eliminates the need for any additional comments in the code!

3 thoughts to “Code Better: Booleans instead of Comments”

  1. You did take 1 step forward but made an additional mistake. The problem is your example has one acceptable function output and that is to return a value with in the height field. With that being side, the code should be a the ident level of the function body, not nested in a “if” statement. Now if your function did 2 different things based on an argument, then the function should have a single if/else statement (after all param error checking) to show case that the function has 2 possible outcomes (or code pathes).

    Here is how I would change your code.

    bool isInsideHeightField =
      (x >= 0) &&
      (y >= 0) &&
      (x < this.heightField.Width) &&
      (y < this.heightField.Length);
    
    if (!isInsideHeightField) //error checking
      return 0.0f;
    
    //everything passed, perform the actual logic 
    //the function was wrote to do
    return this.heightField[x, y];
    

    -Chris

  2. This is just some silly example I came up with to demonstrate a huge if statement, but I would consider 0.0 to also be an output, not an error value (if you think of a height field, 0.0 is likely to be a common value and wouldn’t make a good error value anyway :p)

    Now if the method had an error output, I would do it your way, too (but probably throw an std::out_of_range exception).

    In this case, where I merely pick between returning a default height and a sampled height, I picked an if..else so I would not have to negate the boolean or write a negative isOutsideHeightField check (since humans are quicker to grasp positive statements) and to line up the return statements.

  3. This is cool but it also eliminates the purpose of comment which is to make readers (who may or may not be programmer) to understand the code.

    It’s totally a neat trick!!!

Leave a Reply

Your email address will not be published. Required fields are marked *

Please copy the string 7A9U4l to the field below:

This site uses Akismet to reduce spam. Learn how your comment data is processed.