Defensive programming [closed]

Answer 1

I recommend people write code that is fascist in the development environment and benevolent in production.

During development you want to catch bad data/logic/code as early as possible to prevent problems either going unnoticed or resulting in later problems where the root cause is hard to track.

In production handle problems as gracefully as possible. If something really is a non-recoverable error then handle it and present that information to the user.

As an example here's our code to Normalize a vector. If you feed it bad data in development it will scream, in production it returns a safety value.

inline const Vector3 Normalize( Vector3arg vec )
{
    const float len = Length(vec);
    ASSERTMSG(len > 0.0f "Invalid Normalization");
    return len == 0.0f ? vec : vec / len;
}

Answer 2

In my line of work, our code has to be top quality.
So, we focus on two main things:

1. Testing
2. Code reviews

Those bring home the money.

Answer 3

Similar to abyx, in the team I am on developers always use unit testing and code reviews. In addition to that, I also aim to make sure that I don't incorporate code that people may use - I tend to write code only for the basic set of methods required for the object at hand to function as has been spec'd out. I've found that incorporating methods that may never be used, but provide functionality can unintentionally introduce a "backdoor" or unintended/unanticipated use into the system.

It's much easier to go back later and introduce methods, attributes, and properties for which are asked versus anticipating something that may never come.

Answer 4

In my experience, positively employing defensive programming does not necessarily mean that you end up improving the quality of your code. Don't get me wrong, you need to defensively program to catch the kinds of problems that users will come across - users don't like it when your program crashes on them - but this is unlikely to make the code any easier to maintain, test, etc.

Several years ago, we made it policy to use assertions at all levels of our software and this - along with unit testing, code reviews, etc. plus our existing application test suites - had a significant, positive effect on the quality of our code.

Answer 5

I always work to prevent things like injection attacks. However, when you work on an internal intranet site, most of the security features feel like wasted effort. I still do them, maybe just not as well.

Answer 6

Using Test Driven Development certainly helps. You write a single component at a time and then enumerate all of the potential cases for inputs (via tests) before writing the code. This ensures that you've covered all bases and haven't written any cool code that no-one will use but might break.

Although I don't do anything formal I generally spend some time looking at each class and ensuring that:

1. if they are in a valid state that they stay in a valid state
2. there is no way to construct them in an invalid state
3. Under exceptional circumstances they will fail as gracefully as possible (frequently this is a cleanup and throw)