Defaults – a convenience or a time bomb?

Time BombAll programmers at all languages are familiar with the concept of default values.
Many languages allow default parameter values when calling a functions, some provide a function overloading mechanism which is an expansion of this idea.

For example in python you can have named parameters with default values:

def multiply(v, mult=2.0)
  return v * mult
multiply(5) # returns 10.0
multiply(5, 3.0) # returns 15.0
multiply(5, mult=3.0) # returns 15.0; it's the same as before, only using a named parameter

The concept of default values is found not only in function but in many other places, such as Java Property files.
Java implements by default a nice properties mechanism which lets you quite easily separate between program logic and its data. Just create a file, instantiate a Properties object and read properties from the file.


In Java:

Properties props = new Properties();
URL url = ClassLoader.getSystemResource("");
String myValue = props.getValue("me.prettyprint.my_value");

The properties mechanism is quite convenient and useful; However, in my opinion they went a bit too far with regards to convenience by adding yet another Properties.getValue(String key, String defaultValue) method.
Now you can do this:

// If me.prettyprint.my_value doesn't exist, assign "awful" to myValue
String myValue = props.getValue("me.prettyprint.my_value", "awful");

That’s an example of how default values are more of a time-bomb then they are a convenience. Imagine the following quite typical accidents that happen to programmers daily:

  • Accidentally mistype me.prettyprinl.ny_value in your Java code
  • Accidentally mistype ne.prettyprimt.my_value in the properties file
  • Accidentally mistype the file name ClassLoader.getSystemResource(“”)
  • Forget to package the properties file in your jar; or package it in the wrong way.
  • … you get it, right? It’s so easy to make these mistakes that eventually you will; or the next programmer to edit your files will…

The problem is that since there are default values, the defaults are loaded and you have absolutely no clue that something is going wrong here. The compiler won’t help you b/c you’re not making a syntax error. The program may continue to run fine or appear to run fine until…

To make this situation even worse, many programmers (including myself for a long time) set their defaults to the exact same value as the ones in the properties files.  So what happens is that even if you mistype something once, everything works well by loading the default value, but when you go to your production environment and want to change a property, nothing changes. The property is changed in the file, yet, but it’s not loaded to the program variable because of some silly typos. That is the time-bomb!

Defensive programming means – program as if everything could go wrong; Assumption is the mother of all fuck-ups; Assume nothing! While this is somewhat extreme, I tend to agree to that approach. What could go wrong here is programmers typos or similar small mistakes. Assume they will happen and protect your code against them. Don’t use Properties.getValue(value, devaultValue); Only use Properties.getValue(value).

Sorry, comments for this entry are closed at this time.