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!
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.
-Chris
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 negativeisOutsideHeightField
check (since humans are quicker to grasp positive statements) and to line up thereturn
statements.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!!!