## Friday, November 8, 2013

I recently re-watched the classic spaghetti western "The Good, The Bad, and The Ugly."

The film ends in a classic scene, where our protagonist Blondie ("The Good") is part of a Mexican stand-off at Sad Hill Cemetery versus the antagonists Tuco ("The Ugly") and Angel-Eyes ("The Bad").

In the film, Blondie has an ace up his sleeve, so he does not have to consider the rules of this problem, which is a bit unfortunate as they are pretty interesting. The trivial case where each shooter has 100% accuracy, it is clearly never a good idea to shoot first -- whomever you do not shoot will shoot you. Shooting first simply never is a good idea in this scenario. Good thing Blondie cheated, in other words.

However, when accuracy is less than perfect, things get more complex. Instead of crunching the numbers manually, I decided to let machines do my work for me, and wrote a python script to simulate the stand-off.

Assuming Blondie fires first, these are the results, which offered a few surprises
 Simulation of the Sad Hill Cemetary scenario, 1000 samples/accuracy level

As expected, the high-accuracy scenario means shooting first is a guaranteed way of losing, but if the involved parties are poor marksmen, the rules change. It turns out, if the accuracy of all involved shooters is less than 50%, shooting first is in fact the optimal strategy.

But there's a third domain. If all involved are imperial stormtroopers, with accuracy approaching 0%, it won't matter who fires first; all gunslingers have approximately the same likelihood of surviving, which seems sensible, as the battle will get more drawn out who performed the opening move will play an increasingly smaller role.

The sources used for the simulation are attached below:

### Returning null is the devil, never do it

This, first of all, goes mainly for object oriented languages. In C, you have no option but to return null.

I'm on a bit of a personal crusade against functions that "return null;" Allow me to soapbox a bit.

So many perfectly avoidable bugs arise from this practice. Sure, the exception will probably be called somewhere higher up in the code, and things probably won't be that bad. Unless someone has written a function like say

If your function can fail, and you expect the caller to deal with it, you should throw a checked exception. That way, the caller will deal with it. And if he doesn't, he's explicitly ignored an exception, and he's a moron. If you fail and don't think your caller will be able to deal with it, throw an unchecked exception on the spot. Returning null and having the caller explode at some unspecified time later isn't cool, not one bit. You should fail fast, and make as loud a bang a possible.

If your function can fail, and you communicate this by returning null, the caller may not null check. It's an easy mistake to make. Oftentimes, you need to thoroughly investigate the function being called before even finding how it returns null -- it may happen in something it calls.

Of course, sometimes null isn't an error, but an absence of data. In that case, always return a safe object. Like an empty list, an empty string, and so on. If someone doesn't have a name set, his name isn't null, it is "". If you ask me how many green skinned people live in my neighborhood, I don't say null, I give you an empty list.

Which is why I propose the following strategy to seeing "return null;". Get mad. This function lied to you. It betrayed you. You trusted it, and it rewarded you by stabbing you in the back. It told you it would bring you an object, but it gave you nothing. That bastard! You should be livid at this.

Null-checking is a symptom of bad code, and is a bad solution to the problem at that. The problem at heat is that null checking is very easy to overlook. You oftentimes have to have the code crash before you realize a return value could be null. If you are relying on trial-and-error to make your code stable, you are doing something terribly wrong. Furthermore, a function littered with null checks is significantly more hard to read and maintain, not to mention, if it has 17 null checks already, you almost certainly won't know if it needs another one by looking at it. The very fact that null checks are easily overlooked is reason enough to avoid returning null -- who knows when and how that will backfire. You don't want to be the next Knight Capital. KC's problems weren't down to a NPE, but to a slew of other bad practices, but in a wider sense it's all the same.

The fix to this problem isn't to add null checks, but to re-write the poorly designed function(s). If that isn't possible because it's 3rd party or legacy code, call it indirectly through a facade that guarantees proper error handling.

## Tuesday, November 5, 2013

This is one of my favorite tricks you can use to improve Eclipse. It provides a very nice way of managing your task tags in a large multi-author codebase, where TODOs typically count in the hundreds, if not thousands, and in doing so making the Task View-feature into a very powerful tool for tracking your own development.

 First, set up templates for your tags, including a ${user} and${date} reference.

// TODO (${user}${date}) - ${cursor} // FIXME (${user} ${date}) -${cursor}

You can easily insert these by typing todo and hitting <ctrl><space>. This is useful in that it is possible to keep track of who is responsible for the task tag, but the real magic comes in the next step.

Open the Tasks view, click the little downward-pointing triangle-button in its upper right corner, and select "Configure Contents". You want a new filter based on your user name appearing in the contents of the task tag.

 Configuration example

When this is all set-up, Eclipse will track all of your task-tags.