Right ingredients, no quantities = a recipe for chaos...

In this guest post for the Computer Weekly Developer Network, Keith Hughes, senior consultant at SQS Software Quality Systems writes on methods to help with the code errors posts.

Some programming languages will automatically initialise variables for you. If you are unfamiliar with the syntax and rely on this feature, you run the risk of misusing the language. To avoid creating performance issues, maintenance problems and potential bugs, be sure to correctly initialise data – personally.

Picture this. You’re at home in the kitchen, recipe book in hand. You’ve decided to bake your favourite cake. The list of ingredients is long. It’s a small kitchen with limited workspace so you decide to get your ingredients ready in advance: a bowl with some flour, a bowl with a few eggs, a bowl with butter and so on.

As you fumble around, you accidentally tip a cup of coffee over the ingredients page. It’s unreadable now! Thankfully you’d prepared though, you know what the ingredients are.

On the next page, you’re instructed to add half of the eggs to the flour. Half of the eggs? How many eggs though? You’ve got eggs ready, but no specific amount. If only you’d measured how much of each ingredient you needed.

The bowls, represent the variables of your programme, the ingredients the variable types and the amount of each represents the initial values. Without specific or programmatically assumed initial values, we cannot make any logical reference to our variables at runtime.

All programmers are aware that with most languages, you must declare a variable before spontaneously using it in your code. While some languages allow you to avoid this, most programmers also know that it is poor coding practice.

Declaring a variable involves more typing, but it creates code that runs faster and is easier to maintain. In some of the more dynamic languages, if a compiler encounters a variable that has not been previously declared, it creates it for you. The problem with this occurs when you declare a variable and misspell it later in your code. Now you’ve got two variables – and a potential bug.

A VBA example:

Dim myString as String;
mySting = “Hey”
String myPhrase = myString & ” don’t do that”;

Here, our compiler would tell us that myString has no initial value, but even if we had initialised myString properly, we would now have two variables (myString and mySting) for the price of one.

A case for staying in control instead of relying on the compiler.

A feature of many compilers is the provision of an initial value (auto-initialisation) for your freshly declared variable. These issues do not appear threatening on a small scale, but on a large scale, could have a serious impact on performance. In languages such as C# or Java, our compiler must take a more preventative approach to our un-initialised variables.

An example in Java:

void simpleFunction() {
int i;

In this example we simply declared a variable and it’s type, and tried to get to increment it straight away. But what are we incrementing? It’s mathematically impossible. This makes more sense:

void simpleFunction() {
int i=1;

You can also initialise non-primitive objects in this same way. If Depth is a class, you can insert a variable and initialise it like so:

class Measurement {
Depth o = new Depth();

You can even call a method to provide an initialisation value:

int i = f();

A very simple and frequent occurrence of our un-initialised variable problem is where a conditional statement encases the value assignment. Because the condition itself may never occur, to use the variable we must give it something to offer in all cases:

String color;
String fruit = “Apple”;
If (fruit == “Banana”) {

We immediately get “The local variable colour may not have been initialised”. In my Java IDE, this comes with the suggestion of initialising this on our behalf. In this case our String gets set to null, which is valid value, and a safe and economical assumption that allows the program to compile, but not the correction of a potential bug.

Of course you may be asking the compiler “If you’re so clever why don’t you do it”, but It’s highly likely that something has been forgotten here by the programmer, and providing default values automatically could cover up a multitude of bugs. Forcing the programmer to provide a value is a much safer option.

So, our friend the compiler is there to remind us each time, but we ought to decide what the initial values should be. We should because those default values can, and will, lead to further bugs. This is because they are nothing more than a computer generated workaround. An example of auto-initialisation taking place en masse would be if we were to code a reusable class with a high number of uninitialised variables:

class Measurement {
   boolean t;
   char c;
   byte b;
   short s;
   int i;
   long l;
   float f;
   double d;

void printValues {

This looks like trouble. Let’s call it and see what happens:

Measurement d = new Measurement();


the output from this is:


Because it is a reusable class and we initialise our class with ‘new’, the variables get automatically initialised. While it’s one less job for the programmer it’s also one more aspect they’re not in control of.

In summary, whether it’s to satiate the compiler of a powerful language such as C# or Java, or to avoid careless scripting, the task of declaring and initialising our variables is
something we can avoid initially, but it will catch up with us one way or another.


  • Plan ahead, name your variables carefully and uniquely.
  • Prefix variable names according to type (e.g. strResult is a string).
  • It’s good practice to always declare the variables you will use.
  • Declare the variable type if it is reasonable to do so for the language.
  • It’s good practice to always declare a variable initial value.
  • SearchCIO