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 to many re-reads I always found myself intrigued by the idea of DBC. Yet I never found myself following this interest through, at least in a production environment.

Our team recently came across a bug in which part of the system was using a component in a way which was deemed invalid. We had a suite of tests to accompany this feature, but these tests were unable to highlight the problem. When the object was sent across the wire, the Javascript front end was firing a null reference across, this was out of our control in the back end of the application. As the feature crossed a boundary and spoke to another system defensive programming would have been difficult. All we could do was error and inform the developer what was wrong. Even without defensive programming, the system was currently doing this anyway. We had little to gain.

Here I decided to experiment for the first time in my programming career with code contracts. A contract was applied that said the collection sent into the system must not be null or empty. If so, the second system would blow up informing the developer what was wrong. This contract was a very primitive example of a pre-condition – something that must be true in order for the rest of the following code to execute.

The benefit here came from just a few mere lines of code. Had we tried to program defensively the second systems’ code base would have suffered for little gain. We would need to report the error, add error codes, introduce exception handling and so on, all for a simple defect that could be fixed immediately and potentially never occur again once the developer integrating has configured the components correctly.

One important factor to consider with DBC is the contract violations should never be caught or handled. Every single contract that is violated is a bug. To stop the violation you need to fix the code that is breaking the contract. Likewise contracts make little sense when dealing with a public API. On the edge of the system you should presume your users will make mistakes and “do the wrong thing“, here you must use defensive programming.

Since this day I’ve liberally applied code contracts whenever we cross system boundaries or interact with the infrastructural aspects of our code, e.g. database helpers. This has increased my confidence that the system as a whole has been correctly “glued together”. Another benefit is several bugs have been thwarted thanks to the contracts as unlike unit tests, contracts are always present when enabled, meaning missed boundary conditions can easily be detected.

Hand in hand with our automated test suite, code contracts make a great companion. Never alone will one suffice, but when used in conjunction they can be extremely powerful. So the question is, why aren’t you using them?

Having wrote about the top ten things I discovered in my first year at Codeweavers, I figured it would be time for a follow up after the past two years. In no particular order, a collection of the biggest lessons I have experienced.

• Design by Contract
• Test Driven Development (TDD) is a tool
• Design is Important
• Don’t tie yourself to a Framework
• The Importance of Tools
• Acceptance Testing need not use the Full Stack
• Program for Change (Open/Closed Principle)
• Reinvent the Wheel, Often
• Do it right – violate YAGNI
• Practice, Practice, Practice

I’ll expand on these topics over time in future posts.

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 to control how the lookup was performed. In some scenarios the input would be in a different form, meaning the lookup would need to be carried out in a different manner. An “if” check was introduced to handle this logic. In pseudo code:

public Result Lookup(Request request)
{
    if (request.Id != null)
    {
        // look up an existing quote
        // code specific to an existing quote...
    }
    else
    {
        // look up a new quote
        // code specific to a new quote...
    }
}

The code in question had supporting methods for both paths.

Fast forward a few months and something terrible had happened. Like a plague, this simple conditional I had introduced was spreading. Code that was executed much later on was beginning to perform the same conditional check! At the same time I discovered this problem, I was asked to perform a trivial change as the requirements had evolved. What should have been a five minute job, turned into a few hours of paying back technical debt.

The fix was well overdue at this point. I had to push the conditional statements as high as I could. The closer they were to the edge of the system the better. The by product of this refactor is that the code is a lot clearer now. Each class and method did just one thing, and they did it well. It turned out I was actually able to push the conditional statement so far up that it effectively disappeared into the routing of the system. It was up to the caller to “do the right thing“.

After the refactor:

public Result LookupExisting(Request request)
{
    // lookup an existing quote
    // More code for an existing quote...
}

public Result LookupNew(Request requst)
{
    // Look up a new quote
    // More code for a new quote
}

As each part of the code complies with SRP, I know exactly where to go if there is a problem. For example, if we have any problems with the retrieval of new quotes, I can easily debug and fix the issue. Likewise if we wish to extend the lookup of existing quotes, I can confidently change the code without the fear of breaking the retrieval of new quotes. The other side effect is that I can easily reason about and test the code in question.

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 method

The 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 keyword

At 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 strings

The team managed well with this, one example would be a pair introduced an SKU (Stock Keeping Unit) to encapsulate a string and price. We do this well in day to day development at Codeweavers for domain objects, however we tend to fail in other areas such as data access code. This is one concept we need to try and improve at.

Use only one dot per line

The Law of Demeter in action. Once we cleared up the ideas behind this it was pretty easy for the teams to follow. This is not a dot counting exercise, so it is worth being familiar with the “law”. Much of our code would satisfy this requirement.

Don’t abbreviate

One controversial point that came up from this was regarding the team who chose SKU as a class name. Some of the team disagreed with this naming, though in terms of the domain (a supermarket) this is a perfectly valid name, therefore this did not break the rule. On the whole our code is named well, though our legacy codebases have many abbreviations that can confuse and obfuscate the intent of the code.

Keep all entities small

For new code, this is not an issue, however we find legacy code is given less treatment in regards to the size of our entities. This is something we should try to improve, though the teams found this easy enough during the kata.

Don’t use any classes with more than two instance variables

Personally I find this an odd requirement, providing you keep your classes small as per the previous requirement this tends to be a less relevant task. Of all the rules to follow, this is the one I could not advocate during day to day development providing you keep your classes small.

Use first-class collections

My personal favourite of the rules to abide by, and one I have since adopted into day to day coding. First class collections can simplify, and make code easier to understand as well as maintain and optimize. We have numerous examples of this at play at Codeweavers, and we should try to increase the amount of custom collections we have, as opposed to relying on primitive collections. For example, quotes is a better object than a array of quote.

Don’t use any getters/setters/properties

The hardest of all the rules to follow. Most of the teams tried to get past this rule by simply naming their getters/setters slightly differently. At the end of the day, there were still exposing state unnecessarily. We would never try to enforce such a rule for general development, but for core business logic this principle actually makes sense. The areas where this falls down, is on the boundary of the system, for example user input or output would be such scenarios where getters/setters are the easiest, cleanest solutions. Each team found this requirement the hardest to work with, which mimics my first expose to the object calisthenics challenge.

Recently we had @kevinrutherford in to talk about object discovery. While TDD is a great tool, it is no excuse for some sort of design process. If you don’t, you’ll most likely end up with a mess. This session was based around this principle.

One point that was discussed what that the first few seconds of a test for a new class is the most important part of the TDD process. It is here where you will decide whether to take a state or interaction based approach to testing. This first test will dictate the structure of the new class. Once you start with tests, it becomes difficult to evolve or change the design of a class without friction.

There is generally two types of code at Codeweavers.

• Procedural, e.g. how a computer thinks, e.g. after step x, execute step y.

  car.engine.starter_motor.start()

• Object Oriented, e.g how we think in real life. We tell people to do things.

  car.start()

The trick comes from the fact that just because you use C#/Java/etc.. most of the time you aren’t actually writing OO code. You often end up writing procedural code in a rather obtuse manner. A takeaway from this afternoon was to try and perform more CRC (class-responsibility-collaborator) sessions.

CRC (Object Cube)

During this session we performed a modified version of a CRC. One thing I always find with CRC sessions is how useful they are. The problem I and others find is when it comes to day to day development, I’m too eager to start coding without performing some sort of up front design.

Events

In order to write flexible OO code, you need to hide as much state as possible. While this is great in practice it turns out to be very difficult to achieve in the real world. One method of getting around this is to make use of events aka the observer pattern.

Kevin used a wiki as an example. Consider a page that is updated. If this page was to fire a changed event, then anything that is listening for these events would be notified. They observers could then react once the event was received. The nice thing about this approach is that the code obeys the open/closed principle. New features can be added without the need for the change to have a large, rippling effect.

Nouns and Namespaces

When I was first exposed to object oriented programming, apart from believing that inheritance was the coolest aspect of OO, I was also led to believe that using nouns when designing classes can be useful. It turned out that this was a fallacy. If you follow this advice you’ll end up with a small collection of classes that do everything. The biggest revelation I had during the session came from the importance of namespaces. Using nouns for up front design can be extremely useful if you remember that the noun can potentially be a namespace. This means you’ll end up with a handful of namespaces that are relevant to the domain in question. Inside these namespaces you will have one or more classes that do one thing, and one thing well.

Closing

At the end of the session I was left with many questions and new ideas to test and try out. Using events to hide state, yet allow other objects to interact when required was a real eye opener. However it turns out that when actually trying to implement these ideas in code, it is actually quite difficult due to my current thinking. The plan for the next month will be to explore these ideas in more detail and see what affect it has on my day to day development.