Previously I posted about trivial programming errors, stuff for amateur programmers as in last case. Here we go for a more conceptual mistake.

Answer this question: from 1 to 10, how do you think it's smart to bind the name of a configuration property to the internals of your application?
In my opinion -1. Here I am going to tell you why.

What is god

The configuration is a business aspect your application. And one of the primary goals of a configuration property is to tell the user what application behavior he is modifying. So if the user finds a property like:

myapp.splashscreen.display.seconds=5

The user can understand that he is going to change the amount of time for which the splash screen will be displayed. And, also very important, the user can understand that the option value must be expressed in seconds.

Then, in your code you will have:

1Property configuration = ...
2long splashDelaySeconds = configuration.getProperty("myapp.splashscreen.display.seconds");

Notice that there is a 1 to 1 mapping between the property key declared in the configuration file and the key used in the source code referring to that. This allows modern IDE, like Eclipse, to navigate from the property file to the places on the source code where the property is used. If you never used it, try yourself: open a property file in eclipse and press CTRL clicking with the mouse over a property key; you'll see all the places in your code where that property key is referenced. If your IDE doesn't offer this facility, you can still do a full text search, using the property key, and you'll be able to understand how that configuration property is used.

What is bad

You may be unlucky like me, and get above approach anti-refactored using the following collection of bad practices.

First: including a package name, or any other internals, into the property name.
So you will have configuration properties like this:

com.acme.blahblah.myapp.splashscreen.delay=5000

Much more cryptic for almost everyone.

Not only: if your application internals change, also the option name changes. And there is no reason to change the same option across different software versions if the option is specifying the same behavior.

Second: notice that the time unit is gone. With the assumption that everything is expressed in milliseconds. Thing that could seem very obvious to some "experts", but believe me it is not obvious at all, when in a large system options became hundreds and nobody knows not only the unit of measures, but also what the hell they are supposed to do.

Third: breaking the property key mapping between configuration file and source code. So you will have:

1Property configuration = ...
2long splashDelaySeconds = configuration.getProperty(getPrefix() + ".myapp.splashscreen.delay");
3...

No more "search" will be effective; the developers that maintain that code have to go crazy searching portions of the key, and guessing how the original developer constructed that. It's an extremely enjoyable way to spend your work time, I had this luck before and I can assure you.

Summarizing, the above example, including the package name (or the classname, or other stuff related to the implementation) in the property name is wrong for many reasons:

1. You are binding a business behavior of your application (the configuration) to the internal implementation
2. The same property may be used by classes contained in different packages, so the package name doesn't add any useful information (because it also becomes a wrong information)
3. Mere implementation changes should not be impacting how clients use the software. If you move a class from a package to another... should you update the configuration files? Why?
4. You break the 1 to 1 mapping between the keys specified in the property file and your souce code. Not having that it will become hard to find how a configuration property is used by the code.

So... don't do it.

The "Repetita Juvant Principle" is the counterpart of the DRY principle:

1    @Override
2    public SomeObject getSomeObject() {
3        return super.getSomeObject();
4    }
5
6    @Override
7    public void setSomeObject(SomeObject arg0) {
8        super.setSomeObject( arg0 );
9    }

Then, you may think... this code has been written for some purpose, right? The only purpose of this code could be to expose as public a method that is protected on the superclass. So I checked the superclass and, guess what...? The methods were already public! Simply fantastic.

There are painters that paint with pencils or brushes and painter that paints with a bucket. A bucket is very effective if you just want a canvas filled. An example:

1    private String prefix;
2    public String getPrefix(){
3        return getClass().getPackage().getName();
4    }
5    public void setPrefix(String prefix) {
6        this.prefix = prefix;
7    }

Neat! I don't even think that an IDE can produce dumb stuff like this: set a value, and ignore it. Remembering the principle of the minimum surprise...

Fortunately Eclipse warned me that prefix is never used; in a complete mess like the one I am getting Eclipse is an invaluable ally. Slowly cleaning up...

Here is conceptually¹ how the code was, before the expert's action:

 1public class DoSomethingTask() {
 2    // private fields
 3
 4    public DoSomethingTask(Dependency1 dependency1) {
 5        this.dependency1 = dependency1;
 6        this.dependency2 = new Dependency2(dependency1);
 7        this.dependency3 = new Dependency3();
 8        // ... and so on...
 9    }
10}

Easy uh? How the expert improved that code?
Simple: he removed constructor arguments, and substituted with setters and getters, then he implemented the "lazy instantiation" (wow! a pattern!).

Here is what he did:

 1public class DoSomethingTask() {
 2    // private fields
 3
 4    public DoSomethingTask() {
 5        // nothing here
 6    }
 7
 8    public void setDependency1(Dependency1 dependency1) {
 9        this.dependency1 = dependency1;
10    }
11
12    public Dependency1 getDependency1() {
13        if (dependency1 == null)
14            dependency1 = Dependency1.getInstance();
15        return dependency1;
16    }
17
18    public void setDependency2(Dependency2 dependency2) {
19        this.dependency2 = dependency2;
20    }
21
22    public Dependency2 getDependency2() {
23        if (dependency2 == null)
24            dependency2 = new Dependency2(getDependency1());
25        return dependency2;
26    }
27
28    public Dependency3 getDependency3() {
29        if (dependency3 == null)
30            dependency3 = new Dependency3();
31        return dependency3;
32    }
33
34    public void setDependency3(Dependency3 dependency3) {
35        this.dependency3 = dependency3;
36    }
37
38    // autopilot-mode=on ... same stuff for every single field I was having in the class, and for every class 
39}

Once a colleague asked why he was always providing accessors for all the arguments declared on the constructor. He replied something like: "because when you declare something to the constructor, you are telling the world that the object has those public properties, then you have to provide getter and setters". Have you ever heard a bigger one? Encapsulation and information hiding... these unknown...
There is people around liking to write complete verbose, useless, dumb and harmful code. Hope for them that they are paid on number of lines of code they write.

Yes, it has been an hard day.

NOTE
¹ As I am a contractor, I cannot disclose real code, so I replaced the actual code with conceptually equivalent stuff. BTW, if anybody wants to grab horrific techniques from my horror code gallery, please do at his own risk.

Bad programmer have been able to use Strings in switch statements since the beginning: necessity sharpen sb's wits.

I found a nice pearl regarding the switch on the Strings. Viewer Discretion is Advised!
Look at this:

 1switch(_Temp.getLocalName().toLowerCase().hashCode())
 2{
 3  case -84691548:  // = "get-transfer-url".toLowerCase().hashCode()
 4  {
 5    _getTransferUrl =  _Temp.getFirstChild().getNodeValue().trim() ;
 6    break;
 7  }
 8  case 457922078:  // = "is-authorized".toLowerCase().hashCode()
 9  {
10    _isAuthorized = Boolean.valueOf( _Temp.getFirstChild().getNodeValue().trim() ).booleanValue();
11    break;
12  }
13  case 998201997:  // = "is-charged".toLowerCase().hashCode()
14  {
15    _isCharged = Boolean.valueOf( _Temp.getFirstChild().getNodeValue().trim() ).booleanValue();
16    break;
17  }
18  case -2085709659:  // = "get-resource".toLowerCase().hashCode()
19  {
20    _getResource = new ChargingResource(_Temp);
21    break;
22  }
23  //... continues for about 500 lines more...
24} 

Hoping Java will never change the hash code implementation on the Strings, as actually happened before for other wrapper classes.
At least the author could have used the string itself in place of the comment... I imagine the programmer hard coding the hash code in the switch to boost performance. Very smart...

1switch(_Temp.getLocalName().toLowerCase().hashCode())
2{
3  case "get-transfer-url".toLowerCase().hashCode() :
4  {
5    _getTransferUrl =  _Temp.getFirstChild().getNodeValue().trim() ;
6    break;
7  }
8
9} 

Still horrible, and designed to fail (hash codes can conflict).

Maybe I am beginning to become a conservative dinosaur, but since JDK 5 (and maybe 1.4) I don't see the reason of many of the "improvements" that have been included and will be included in the Java language. Simplicity made of Java a success. I see every day pile of code written by "experienced" developers capable to overpatternize banalities and still unable to handle properly an exception. What's the matter of adding more complexity and features? Also including harmful ones like String in switch statement... Personally I think that the switch statement should be deprecated tout cour.

I don’t know what XPers whould say about this, but I found it useful. Maybe someone could say: if you are not able to test something of your API, maybe you’ve badly designed your components… or: you should’n test this, because this is internal specifics of your object and you don’t have to know or test it: if you change internal implementation your test will fail. or… you need this ‘xyz’ test pattern. or… I don’t know. This is why following code has been posted in my ‘horror code’ category.
Here’s the base class I used to implement some junit TestCases that need to access to internal details of my objects:

/**
 * $Id: InternalAccessorTestCase.java 77 2005-12-06 14:46:42Z luigi $
 */
package it.newinstance.test.util;

import java.lang.reflect.Field;
import java.lang.reflect.Method;

import junit.framework.TestCase;

/**
 * Base class for TestCases that need to access private fields and methods
 */
public abstract class InternalAccessorTestCase extends TestCase {

    protected static Object getFieldValue(Object o, String fieldName) {
        try {
            return getField(o.getClass(), fieldName).get(o);
        } catch (Exception x) {
            throw new RuntimeException(x);
        }
    }

    protected static Object invoke(Object o, String methodName, Object[] args,
            Class[] types) {
        try {
            return getMethod(o.getClass(), methodName, types).invoke(o, args);
        } catch (Exception x) {
            throw new RuntimeException(x);
        }
    }

    private static Field getField(Class clazz, String fieldName)
            throws NoSuchFieldException {
        try {
            Field f = clazz.getDeclaredField(fieldName);
            f.setAccessible(true);
            return f;
        } catch (SecurityException e) {
            throw new RuntimeException(e);
        } catch (NoSuchFieldException e) {
            if (clazz == Object.class)
                throw e;
            return getField(clazz.getSuperclass(), fieldName);
        }
    }

    private static Method getMethod(Class clazz, String methodName,
            Class[] types) throws NoSuchMethodException {
        try {
            Method m = clazz.getDeclaredMethod(methodName, types);
            m.setAccessible(true);
            return m;
        } catch (SecurityException x) {
            throw new RuntimeException(x);
        } catch (NoSuchMethodException x) {
            if (clazz == Object.class)
                throw x;
            return getMethod(clazz.getSuperclass(), methodName, types);
        }
    }
}

I needed to check the internal state of an object, that does some job, but does not expose anything that can be tested. I just parse some xml and instantiate an object with its components, then I needed to test that the composition has been done as I expect.
This is how my test appears:

/**
 * $Id: ParserTest.java 81 2005-12-06 23:08:42Z luigi $
 */
package it.newinstance.test.watchdog.xml;

import java.util.List;

public class ParserTest extends InternalAccessorTestCase {

    public void testServerWithOneMonitorAndOneListener() throws Exception {...}

    public void testServerWithMonitorWithParametersAndNullListener()
            throws Exception {
        String xmlPath = getCurrentPath()
                + "/ServerWithMonitorWithParametersAndNullListener.xml";
        Server s = new Parser(Util.getStream(xmlPath)).parse();
        assertNotNull(s);
        List monitorEntries = (List) getFieldValue(s, "monitorEntries");
        assertTrue(monitorEntries.size() == 1);
        for (Object monitorEntry : monitorEntries) {
            MockMonitorWithParameters m = (MockMonitorWithParameters)
                getFieldValue(monitorEntry, "monitor");
            assertEquals("thisIsATest", m.getStringValue());
            assertEquals(10, m.getIntValue());
            assertEquals(5.5, m.getDoubleValue(), 0.0D);
            assertEquals(true, m.isBooleanValueTrue());
            assertEquals(false, m.isBooleanValueFalse());
            assertEquals(new Integer(15), m.getWrapperIntegerValue());
            assertEquals(new Double(3.14D), m.getWrapperDoubleValue(), 0.0D);
            assertEquals(Boolean.TRUE, m.getWrapperBooleanValueTrue());
            assertEquals(Boolean.FALSE, m.getWrapperBooleanValueFalse());
            List listeners = (List) getFieldValue(m, "listeners");
            assertTrue(listeners.size() == 1);
            for (Object object : listeners) {
                Listener listener = (Listener) object;
                assertEquals("MyListenerName", listener.getName());
            }
        }
    }

    private String getCurrentPath() {
        return getClass().getPackage().getName().replace('.', '/');
    }
}

Calls to getFieldValue utility methods, makes access to private member variable of object(s) to be tested. I made two methods: getFieldValue to access private field of objects, and invoke, that is able to invoke private methods of my test objects.

Maybe this code is horror enough (?): recently I am neglecting this blog, and also posting so few about code… I’m doing not much interresting coding, but I enjoy what I read on jroller and other blogs…

It was a late evening when I fall in buggy a code like this:

Destination newDestination = null;
if (! originalDestination.getId().equals(getDestinationId()));
{
    newDestination = context.loadDestination(getDestinationId());
    prefix.setDestination(newDestination);
}
context.save(prefix);
if (newDestination != null)
{
    newDestination.addPrefix(prefix);
    originalDestination.removePrefix(prefix);
    context.save(originalDestination);
    context.save(newDestination);
}

When the first if block is true, the second one will also be true, because the line at 4 will force newDestinatio to be not-null. The strange thing was that the second if-block was always executed, so I started to do step-by-step debugging. Working with cglib-proxied objects (hibernate) I was starting to think on some bug somewhere in the framework. Wrong! The bug is there and was under my nose but nicely hidden. Can you see it?
Check the end of line 2, at the end of the if condition... there's a ";" so that the first if will execute an empty statement, and the block under the if will ever been executed. It was so surprising checking internal values thru the debugger and then see the if being executed even if the condition was false!

I was surprised tha Eclipse does not pointed me over the code inconsistency (a warning). If you enable warning on empty statements (Preferences->Java->Compiler->Errors/Warning->Potential Programming Problems->Empty Statements), you could notice easier errors like this. But there's no way to define a warning of blocks {} without a previous construct (if/while/for...). Even if sometime correctly used, empty blocks are always ugly (i.e. for(int i=0; i>x; doSomething(i++)); ugly!). So I enabled this as an error, in eclipse compiler. Would be nice to be warned on instruction blocks without a construct on top (like the range of lines between 3 and 6).

 1String alias = "cd";
 2
 3StringBuffer expression = new StringBuffer("select ");
 4expression.append(alias).append(".account.name, ");
 5expression.append(alias).append(".startDate, ");
 6expression.append("sum(").append(alias).append(".duration), ");
 7expression.append("sum(").append(alias).append(".cost), ");
 8expression.append(alias).append(".account.id from ");
 9expression.append(Test.class.getName()).append(" as ").append(alias);
10expression.append(" order by ").append(alias).append(".startDate desc ");
11
12String result = expression.toString();
13// hibernate.executeQuery(...result...);

Cool! Only real programmers can read it, isn’t that? ]:)
You can imagine, that I love to write code this way… Jokes apart, imagine the time wasted beeing caught executing wrong queries and debugging this!
I tried to discuss this rule, but no-way… being a contractor, I always have to surrender to major forces :-), and this costs me pains. But at least this time we’ve discussed (a little, and here’s my rant). So the code it’s there. Fortunately in Hibernate 3.x we use Criterion and Projection APIs, so wrinting this kind of code is nomore in my task list. Few!
But going back at that time, you may think that a code like this below is easier to read but slower to execute:

 1String expression =
 2    "select " +
 3        "cd.account.name, " +
 4        "cd.startDate, " +
 5        "sum(cd.duration), " +
 6        "sum(cd.cost), " +
 7        "cd.account.id " +
 8    "from " +
 9        Test.class.getName() +
10        " as cd " + "order by " +
11        "cd.startDate desc";
12String result = expression;
13// hibernate.executeQuery(...result...);

If you think that it’s slower, you are wrong! Compilers are there to optimize code. String concatenations is made using StringBuffers by the compiler. The compiler can also inline string constants in a single one. Here’s an example on how the compiler can arrange our previous code:

1String expression = (new StringBuffer("select cd.account.name, cd.startDate, sum(cd.duration), sum(cd.cost), cd.account.id from ")).append(Test.getName()).append(" as cd ").append("order by ").append("cd.startDate desc").toString();

I’ve made a little class to compare performance between StringBuffers and String Concatenations for methods building queries like this.
Here’s the code (results follow)

 1public class Test {
 2    public interface Repeatable {
 3        void iteration(long loopId);
 4    }
 5
 6    public static long repeat(int times, Repeatable repeatable) {
 7        long initial = System.currentTimeMillis();
 8        for (long c = 1; c <= times; c++)
 9            repeatable.iteration(c);
10        long elapsed = System.currentTimeMillis() - initial;
11        return elapsed;
12    }
13
14    private static Repeatable stringBufferTest = new Repeatable() {
15        public void iteration(long loopId) {
16            String alias = "cd";
17            StringBuffer expression = new StringBuffer("select ");
18            expression.append(alias).append(".account.name, ");
19            expression.append(alias).append(".startDate, ");
20            expression.append("sum(").append(alias).append(".duration), ");
21            expression.append("sum(").append(alias).append(".cost), ");
22            expression.append(alias).append(".account.id from ");
23            expression.append(Test.class.getName()).append(" as ").append(alias);
24            expression.append(" order by ").append(alias).append(".startDate desc ");
25            String result = expression.toString();
26        }
27    };
28
29    private static Repeatable stringConcatenationTest = new Repeatable() {
30        public void iteration(long loopId) {
31            String expression =
32                "select " +
33                    "cd.account.name, " +
34                    "cd.startDate, " +
35                    "sum(cd.duration), " +
36                    "sum(cd.cost), " +
37                    "cd.account.id " +
38                "from " +
39                    Test.class.getName() +
40                    " as cd " + "order by " +
41                    "cd.startDate desc";
42            String result = expression;
43        }
44    };
45
46    public static void main(String[] args) {
47        for (int loopCount = 1; loopCount <= 5; loopCount++) {
48            int times = 1000000;
49            long stringBuffElapsed, stringConcatElapsed;
50
51            stringBuffElapsed = repeat(times, stringBufferTest);
52            stringConcatElapsed = repeat(times, stringConcatenationTest);
53
54            System.out.println("Results for iteration " + loopCount);
55            System.out.println("StringBuffer Build. " + stringBuffElapsed);
56            System.out.println("String  Concatenat. " + stringConcatElapsed + "\n");
57        }
58    }
59}

Here the output:

Results for iteration 1
StringBuffer Build. 3085
String  Concatenat. 1492

Results for iteration 2
StringBuffer Build. 3044
String  Concatenat. 1612

Results for iteration 3
StringBuffer Build. 3205
String  Concatenat. 1793

Results for iteration 4
StringBuffer Build. 3745
String  Concatenat. 1783

Results for iteration 5
StringBuffer Build. 3505
String  Concatenat. 2353

For this case, String concatenations is twice faster than StringBuffer!

Conclusions: don’t use String concatenations to build big strings (expecially inside loops), use StringBuffers everytime possible, but leave your source code readable! And… never forget Rules of Optimization. Personally, I prefere code (a little) slower but more readable. And, when possible, faster and more readable, like in this case.