Knives Episode 29 Published!

A quiet murder, followed by a confrontation. Martin doing what Martin does best. But this time, his best may not be enough.

This episode went well, writing-wise; there were some details I had to work out for realism but the overall chain of events was pretty set. The rest was a matter of the small things. If there’s one thing I regret about the serial format, it’s that when I read an episode long since published I often wish I spent more time on the small things. It’s a lesson the Kansas Bunch has been trying to pound into my head for years now: The life of the story is in the little details.

We have in the narrative an honest-to-god MacGuffin now, and I have mixed emotions about that. It’s a time-honored device that appears in some of the best stories ever, but it also serves as a crutch in some pretty bad writing (see, “The Quest for the Important Thing to Defeat the Evil Guy”). I had intended to resolve this particular item fairly quickly, making it more a clue to the mystery rather than an object of great contention, but… well. I might not.

Please enjoy Episode 29.

Defensive Programming: Put the Guards Near the Gate

We can file this one under “not interesting to pretty much anyone who reads this blog,” but it’s an important concept for writing robust code. This is part of a discipline called Defensive Programming.

Let’s say you build yourself a castle in a clearing in the woods. There is one path to the front gate, and you need to guard it. “Hah!” you think, “I’ll put the guards where the path comes out of the woods, to stop shenanigans before they even get close!” You post the guards out there in a little guardhouse, secure in the knowledge that no bad guys will reach your gate.

Until someone makes a new path. Perhaps when the new path is created the path-maker will notice that there are guards on the other path and put a little guardhouse on the new path as well. But perhaps not.

In software, it’s the difference between code that says, “when all conditions are right, call function x”, and having function x test to make sure everything is OK before proceeding.

Putting the guard by the trees:

    function x(myParameter) {
        myParameter.doSomething();
    }

    thing = null;

    ... other stuff that might or might not set 'thing'

    if (thing != null) {
        x(thing);
    }

This is fine as long as everything that calls function x knows to check to make sure the parameter is not null first. It might even seem like a good idea because if ‘thing’ is not set you can save the trouble of calling the function at all. But if some other programmer comes along and doesn’t know this rule, she might not do the check.

    // elsewhere in the code...

    anotherThing = null;

    ... other stuff that might or might not set 'anotherThing'

    x(anotherThing); // blammo!

Better to move the guards close to the gate:

    function x(myParameter) {
        if (myParameter != null) {
            myParameter.doSomething();
        }
    }

Now when someone else writes code that calls function x, you can be confident that your guards will catch any trouble. That doesn’t mean you can’t ALSO put guards out by the edge of the forest, but you shouldn’t rely on them.

2