Defensive coding, interfaces and code noise.

Today I’ve been trying to balance several factors in my code following a code review. The first 2 are defensive coding and code noise; some people suggest that wherever an object is used it should first be checked for null, but then what do you do if it is null? sometimes the structure of your code ensures that it is never null. Also having all the null checks just introduces a lot of code noise. One solution would be to have non-nullable types (yes please!), but until that is possible in C# I need some guidelines as to when to check for null.

If an object is guaranteed to be non-null do not bother adding a check for null.
If an object is returned from a method on an interface then the return should always be checked for null.
If an object is returned from a method on a concrete class then the return should be checked for null unless the class has some sort of a guarantee that a null value will never be returned.

These last 2 guidelines show a difference between using an interface and a concrete instance. When you use an interface you can’t guarantee the behaviour of the implementing class, and due to the increased flexibility it would be a bad idea to make these assumptions based on the current implementation (particularly when the implementation is injected or similar). This makes me wonder whether I should spend more time balancing the use of interface dependencies and concrete dependencies.

Any comments welcome; what guidelines do you use for checking for nulls?

Advertisements

About Alex McMahon

I am a software developer, interested in .net, agile, alt.net. I've previously specialised with .net 3.0 technologies like WCF, whereas now I am trying to specialise in agile development and best practice and patterns. I am obsessed with looking at the latest technologies, tools, and methods, and trying them out. I am currently employed by Rockwell Collins in the UK.
This entry was posted in development, guidelines. Bookmark the permalink.

2 Responses to Defensive coding, interfaces and code noise.

  1. ALAGARSAMY says:

    Added to your rule of thumb:

    1) If the object is a Business Object ( say for example you are saving in a database)

    Always check for null. Because there is always a possibility that some data in the database might have been deleted.

  2. Alex McMahon says:

    @ALAGARSAMY:
    Not sure we have the same definition of a ‘Business Object’, but I’d only check for null on creation of the business object from the database, so if the database is missing any values to create a valid instance of the business object it will fail at creation time; Subsequent uses can forget about the null check.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s