A former colleague of mine was recently trying to sort out a question in his head once and for all: which is better, declaring a variable inside a loop or outside of a loop? A Google search lead him to this thread on Javalobby and knowing my feelings on the subject he thought I’d find the comments interesting. I certainly did but I wasn’t surprised by some of what I read.

It’s to be expected that most conscientious developers will have one eye on performance while writing their code. For example, in the Java world there are some obvious things you need to watch for to avoid unnecessary performance hits – using StringBuilder instead of String while building strings for instance or avoiding Vector when you don’t need thread safety. The real problem occurs when developers are tempted into doing little tricks that they think will improve the performance of their code when they don’t know where the real performance bottlenecks are in the first place. This is premature optimization and and like many things that are premature¹ it can cause embarrassment and quite a few problems.

The use of the keyword final in Java is a perfect example. You can use it, as it was intended, to explicitly seal the implementation of a class so that it cannot be sub-classed, or a method so that it cannot be overridden by a sub-class. You could also choose to use it to improve performance of method calls by removing them from the vtable. Think about what you are doing first though. Nothing you mark as final can be subclassed or overloaded. If you believe that code should be self-documenting then you are making a bold statement about its design. Regardless, you’re restricting the behaviour of those classes when other developers go to use them². Is that what you want? Now think about the performance gain you’ve achieved. If you’re doing this before you’ve profiled the code to discover the real bottlenecks³ it’s the coding equivalent of ordering four Big Macs, two large fries, an apple pie and a Diet Coke.

The question about whether or not to declare a variable inside or outside a loop can be sort of couched in the same terms. There are going to be times where if you are creating a new object instance it might be more efficient to do that outside a loop rather than inside but that is down to the cost of invoking the object’s constructor. If you’re just talking about declaring a variable which will have an object reference assigned to it then you’re asking the wrong questions about your code. The rule should always be to keep your code clean and simple and in this case a good general rule of thumb is to keep the usage scope of a variable as small as possible.

Instead of doing this

private void someMethod() {
    SomeObject blah;
    for (int i = 0; i < 10; ++i) {
        blah = getBlah(i);
    }
}

you’re almost certainly much better off doing this

private void someMethod() {
    for (int i = 0; i < 10; ++i) {
        SomeObject blah = getBlah(i);
    }
}

For starters there’s no chance that the object will get re-used out of context (accidentally or otherwise) thereby reducing the potential for any bugs. Secondly it makes refactoring much easier. If you decide later on to extract the contents of the loop as a method everything that is local to the scope of the loop should come out cleanly. The bottom line is that the code is cleaner and easier to maintain. That is usually half the battle when it comes to having performant code but notice that the two reasons I give for doing it this way, and there are others, aren’t explicitly about performance.

Feel free to get into arguments about what kind of bytecode is generated when you declare a variable inside or outside a loop after you have run a profiler to find where the real bottlenecks are and have eliminated them⁴. I can practically guarantee you that you won’t have to resort to any tricks to improve performance. Chances are the problems will be with some part of the implementation. You may be using the wrong collection types, using the wrong search algorithm, not pooling resources correctly etc. I would be really surprised if attempting to influence how quickly a method was being called or how long it was taking to declare a variable in a loop resulted in a significant performance improvement in your code.

The first question any developer should ask themselves when writing new code, after the obvious one of what should this code actually do, is how clean and simple is the design? Inevitably a clean and simple design will be more efficient than a cluttered, trick-laden one. Keep it simple, make it work and then make it fast. As with most things in this business, the 80/20 rule applies and you’ll probably find that 80% of the time taken will be spent in 20% of the code. Find that 20% and improve its performance and you’ll see real and meaningful gains in the overall performance of your code but concentrate first on writing clean, clear and simple code.

Writing “clean and simple” code can be a subjective exercise but there are things you can do to help the process. Over the next few weeks I’ll be posting a series of articles on how test-driven development and the new kid on the block, behaviour-driven development, can help you achieve this goal.

I will now put the soapbox away.

– Fintan