How object calisthenics can save the night

Last week we had a 24 hour hackathon at work. And I ended up using an old trick I've mentioned before.

In the project I worked on we needed a simple database consisting of a number of id-name tables and their relations. Since all these tables used integers as key and we wanted to work on an in memory representation I decided to use the old no-primitive-types trick from object calisthenics.

A friend used this trick a while back and caught several bugs that way so I decided to do the same thing since I assumed we would not write a lot of tests in our 24 hours and flipping two integer identifiers in a relational table would vastly change the result. So for every table we had I created a specific identifier class that abstracted away the integer. Turned out this was a good choice since we copied a lot of code during this period and changed which hash table we were using.

So why didn't we write unit tests to save the night instead? Well we could have. Unless we made the same mistake of switching variables in the test code. And we were prototyping so there was only unit tests for the most important parts of our algorithms. So even if this was for my regular work I would favor using specific types for these identifiers because it will save me from stupid bugs both in production code and in test code regardless of how much test code I write. Letting the compiler find your errors is always faster than finding them using unit tests!