Defensive Programming ensures that a program will continue to work under unforeseen circumstances and usages. It is above all a way of thinking, of working, that consists of writing code waiting for the worst to happen. This kind of programming is defined as “a kind of defensive design thought to ensure that the system will continue to work under unforeseen circumstances.” The approach is a must in projects where the high availability, the consistency or the security are necessary. In this post, we’ll see some steps to take to adopt this philosophy of work.

1 - Never trust data entered by the users

Always be prepared to receive some unexpected things. You should be aware of the data that your users put into the system, it must be validated to see if it’s according to the expected. In fact, you should be aware of all data that enters the system. Although validating the data after the user types it is a must, it’s also good to not let them type anything wrong in the first place (e.g. typing a negative number on an Age field). This kind of approach, preparing for unforeseen situations, is at the core of defensive programming.

2 - Do not reinvent the wheel

Do not reinvent the wheel

Write your own code or use a third-party library (or package)? If you find a well-maintained library that suits your needs, it’s often a good idea to go with it. Usually, third-party libraries are tested and approved by hundreds or even thousands of developers, it’s updated with no extra effort (not your effort), it’s more mature, optimized, and the list goes on. Besides, it’s already there, why would you do a job that’s already done?

3 - Don’t trust the developers

Defensive programming has a lot in common with the concept of Defensive Driving. Defensive Driving says that everyone is susceptible to make mistakes, and therefore, one driver should pay attention not only to his or her own car but in the other drivers and the surroundings too. On Defensive Programming, this concept can be applied by making peer reviews. Peer Review is when a developer writes some functionality and then hands it to another developer for them to see if the code that the first one wrote is correct and in accordance to the standards of the project or organization they are in.

4 - Write a SOLID code

SOLID principles

SOLID is an acronym that represents 5 principles for object-oriented programming. The principles are as follows:

Single Responsibility Principle: a class should have one and only one responsibility; Open/Closed Principle: a class must be open to extension, but closed to modifications. Liskov Substitution Principle: an instance of T could be replaced by an instance of G, if G is a subtype of T, without affecting the coherence of the program. Interface Segregation Principle: this principle says that is preferable to have many interfaces that are specifics for each client than having one general interface for everybody. Dependency Inversion: it says it’s better to be dependent on abstractions than implementations.

This is the hard part when it comes to Defensive Programming: writing a good code. SOLID is one of those things that many people know, but few put into practice.

5 - Write tests

Unit tests are proven to be one of the best ways for developers to improve the quality of their code, the tests are especially useful when refactoring code, as the tests will assure that, even though the code changes, the behavior is still the expected. Writing unit tests will help us test modules, but also help us to check how we structured our objects because some ways to write code produces codes more easy to test than others.


Creating a system that deals perfectly well with any kind of situations is not an easy task, there are an enormous amount of paths that a user can take inside a system, but, it’s our job to ensure that as many of them as possible will be free of problems. Defensive programming is a good way to improve the overall quality of the code.