It doesn’t matter how smart you are, it doesn’t matter that you are highly experienced, there will still be times when you simply need to look at the problem, rather than think your way through it. Of course thinking is useful, and a pre-requisite habit for any successful developer to foster, but even if you’re smart you still need to look. An earlier post described the philosophy behind this concept, so I won’t labour the point here, instead I’m going to describe a real-life experience to demonstrate what I’m talking about.
The code was running in a bank (which shall not be named) and didn’t work as expected. The developer (who shall not be named) asked me why it doesn’t work as expected and it’s “probably a bug in perl”. Thinking this was a little unlikely, but always possible, I scanned the code and the first thing which struck me was the lack of any error handling when a particular file was opened. The file in question was simply opened and read, and when I asked “what happens if the file isn’t there?” the response I got was “that can’t happen!” (famous last words).
Here’s the relevant snippet from the code to give you an idea of what we’re dealing with:
open( $fh, $file, ‘+<‘ );
while ( $fh ) {
# do some stuff..
}
exit;
Running the program, just “did nothing”, there was no output, there was no result, it was as if there was no (do some stuff) code running at all. Now, please, don’t say “this is so obvious”, or “it’s not a real-life experience”, or “what an awful coding job”, or whatever else comes to mind. The point is that this DID happen, and not only once, I’ve seen exactly the same coding approach from several very experienced programmers who should probably know better, and more often than I can count. I said “please just humour me here and let’s LOOK at the status of the system error variable ($!) after the open file command”, and suggested he put a print statement around the “open file” statement to echo the value of the variable. The (important part of the) new code looks like this:
open( $fh, $file, ‘+<‘ ) or die( “Can’t access the file: $!” );
Remember that it’s simply not good enough to assume the file is there, to assume it’s readable or writable,to assume nothing else happened and to just continue merrily along assuming that everything is ok. You have to check the relevant variables and system states, wherever and whatever that means in each case. Sure enough, as you’re all expecting, the next time we ran the program we got a nice error message printed to STDERR for us to read:
Can’t access the file: Permission denied!
One red-faced developer then changed their script to include the new feedback as well as the filename for reference and, to his credit, even added a check for the return value from open at the same time.The system error variable is there for a reason, and you need to check it. This deceptively simple example reminds us to LOOK at the state of our programs before continuing. The changes to the code brought us to something which looked a lot like this:
$pid = open( $fh, $file, ‘+<‘ )
or die( “Can’t access the file ‘$file’: $!” );
if ( !$pid ) {
# complain about no system pid
} else {
# do some stuff…
}
close( $fh );
exit;
The errant system file permissions were fixed, the program ran on to finally “do some stuff”, and we all learned something in the process. Checking the status of error variables is why these variables are provided in the first place, and ensures that our code has the best chance of working in the real world, like at the bank. It’s not important to have short and clever looking code, it’s important to have working code.