Programmer's version of Murphy's law: Any code that can go wrong, will go wrong.
Defensive coding means you put a little bit of effort to think how your code will be used and when/where it can fail. Think of interfaces to your code. Then avoid the buggy situations. You think of where your code can fail while you write it. Test suites can help once your code takes some shape and also when you make changes to your API.
An example: Suppose your code is returning an array or a collection. In the following code the list to be returned is initialised to an empty list. This helps to avoid a NullPointerException.How?
class SomeName
{
ArrayList<String> values;
public SomeName()
{
//List with 0 elements
values = new ArrayList<String>();
}//constructor
public void doWork()
{
//We do some work which generates an array.
}//
public String[] getResults()
{
return values;
}//
}//class
If the list object was not initialised and it was not created, the calling code could fail. Suppose the calling code did this. The null value returned (if it was never set) would fail on list.size(). list would be null.
//Calling code
list = someNameObj.getResults();
for(int i = 0; i < list.size(); i++)
{
//..............
}//for
If this is buried in tons of code with re-throws (does happen) then we have lost time tracking it. As trivial as this might seem, this scenario comes up frequently during reviews and even in standard APIs. A small foresight can avoid a nasty bug. Defensive programming helps save time as you move forward in your project.
Defensive coding means you put a little bit of effort to think how your code will be used and when/where it can fail. Think of interfaces to your code. Then avoid the buggy situations. You think of where your code can fail while you write it. Test suites can help once your code takes some shape and also when you make changes to your API.
An example: Suppose your code is returning an array or a collection. In the following code the list to be returned is initialised to an empty list. This helps to avoid a NullPointerException.How?
class SomeName
{
ArrayList<String> values;
public SomeName()
{
//List with 0 elements
values = new ArrayList<String>();
}//constructor
public void doWork()
{
//We do some work which generates an array.
}//
public String[] getResults()
{
return values;
}//
}//class
If the list object was not initialised and it was not created, the calling code could fail. Suppose the calling code did this. The null value returned (if it was never set) would fail on list.size(). list would be null.
//Calling code
list = someNameObj.getResults();
for(int i = 0; i < list.size(); i++)
{
//..............
}//for
If this is buried in tons of code with re-throws (does happen) then we have lost time tracking it. As trivial as this might seem, this scenario comes up frequently during reviews and even in standard APIs. A small foresight can avoid a nasty bug. Defensive programming helps save time as you move forward in your project.
No comments:
Post a Comment