Skip to main content


Showing posts from 2013

The Anti If Campaign

Firstly if you are unaware of what the Anti If Campaign is, I advise you to take look before coming back. My first impression a few years ago was the site must have been some sort of spoof. Programming without "if" statements, this was crazy nonsense. After all the "if" statement is one of the core constructs of any language. If you look deeper however the campaign is not advocating the abolition of "if" statements, it is simply encouraging cleaner code by removing the likes of type checking and control coupling. This can be achieved by the use of Polymorphism and abiding by the Single Responsibility Principle (SRP).The Anti If Campaign is relevant as I have recently had first hand experience of what the supporters are campaigning against. I was working on one of our greenfield projects where I had violated SRP for an easy win. We had a class which would look up a quote based on some input criteria. I allowed this input …

Why are you not using Design by Contract?

When learning to program I distinctly remember coming across the concept of placing asserts within your code. Assert statements are primarily used for "things that cannot happen", but in my early days I was too focused on the stuff that was supposed to happen!"Defensive programming" was also introduced. Principles such as "Never trust the user" and "80% of your code will be validation and verification" were highlighted. Despite these introductions many years ago, the concept of asserts never stuck with me. Yet I program defensively like there is no tomorrow.The use of asserts can be extended into "Design by Contract" or DBC. In DBC the developer makes use of pre-conditions, post-conditions and invariants. Some languages such as Effiel have taken DBC as a core feature while other languages leave DBC up to libraries.One of my favourite programming books is the Pragmatic Programmer. Having stood up …

3 Years at Codeweavers

Object Calisthenics

Recently I ran a session on Object Calisthenics. I was first exposed to this challenge a few years ago and personally found it a fun, yet difficult experience. This is intentional as the challenge is designed to push the boundaries of best practices. The instructions are simple, there are nine rules to follow that must be obeyed during a traditional kata. We chose the Checkout Kata as the backdrop for this session. The teams feedback is as follows.Use only one level of indentation per methodThe team found this easy, and we discussed that following this to some degree in day to day development would be beneficial. Limiting the amount of nested code you have can improve readability quite substantially.Don't use the else keywordAt first this seemed a no brainier, until people realised it meant to favour polymorphism and not simply relying on an early return (implicit else).Wrap all primitives and stringsThe team managed well with this, one example w…