August, 01 2003

Inspired by Cedric Beust’s thoughts on coding conventions, I present my contribution to the discipline of writing unmaintainable Java code. These hints and tips have been collected from a variety of Java projects, over many years.¹ In the hands-on spirit of industry-standard, panic-driven development, this list concerns itself purely with low-level coding and cowboy-style pseudo-design techniques.

In no particular order:

• Declare classes and methods ‘final’, for no good reason. If you are have trouble coming up with some bad reasons, here are two: performance, and distrust of the abilities of the developer who comes after you.

• Initialise class members where they are declared, and then initialise them again in the constructor. This practice is without any defensible rationale.

• Initialise class members with zero, false and null. The maintenance difficulties created are slight but gratuitous.

• When coding with arrays, use null rather than a zero length array. This causes every for loop iterating over the array to need wrapping with if (array != null). A similar effect can be achieved when coding with collection classes.

• Separate function from the data it operates on. Insist all data be stuffed into logic-free Java beans, and all logic into data-free utility classes. Have the courage to repudiate the OO-paradigm.

• Design in such a way that programmers need to write code in the form of object.getX().getX(). For bonus unmaintenance points, ensure that getX() and getX() return different types.

• Write 9 line if statements.

    if (something1()
        && something2()
        && something3()
        && something4()
        && something5()
        && something6()
        && something7()
        && something8()
        && something9()) {
                ...

• Here is a trick for storing numeric values in database rows. Allow only positive values to be stored into the row. If the value is allowed to be negative at runtime, have the programmer indicate the sign of the value with a flag stored elsewhere in the database row.

• Use as many EJBs as possible, wherever possible. Some ideas to get you started: each table in your database schema can support at least one CMP EJB; a stateless session bean makes an ideal interface, so use one to front each CMP EJB; finally, tie together your entire system with a further layer (or two!) of EJBs.

• When coding long constants, use a lower-case ‘l’ in preference to upper-case ‘L’. Even with plain font such as Courier, 1l can cause all kinds of havoc. And with proportional san-serif fonts being supported by more and more IDEs, things can only get less clear and more unmaintainable.

• Never use a raw boolean values in a condition. The classic example is ”if (number.isEven() == true) {…”, a trifle which is easily ignored by a maintenance programmer. However, given the right opportunity and a small amount of thoughtlessness, this simple device can finesse one line of code into five:

    if (number.isEven() == true) {
        return true;
    } else {
        return false;
    }

• It is a little known fact that many commercial J2EE servers are quite resilient to references to unused or non-existent classes and methods in configuration files. Recently, while working on an EJB with three finder methods, I was pleasantly surprised to find five finder method definitions amongst the ejb-jar file extensions.² Experiment to see what kind of cruft your app server allows.

• Unusable programmatic interfaces should be natural consequences, not brute-force design decisions. When developing library code, concentrate on least-effort implementation, performance, or—if all else fails—internal elegance.

• “Ctrl-C, Ctrl-V” is your friend.

• And finally, make sure that at least one of the applications classes exceeds five thousand lines. This is especially important if the IDE in use cannot handle such large files gracefully.

PS: Most of these are not fatal—they are simple to correct, and would be caught in even a cursory code review. Even so, I am thankful that I haven’t come across a single project that has put all of these into practice.

¹ It’s just a bunch of notes really, but there would be too much irony in any more formal presentation.

² I couldn’t be bothered to work out which two were not being used, so I left them all there while I added a new one.

My son Connor is five. I asked him about his week at school.

Connor’s favourite thing for the whole week was ‘Toy Time’. Every toy time he played with the Duplo; he says he “never takes a break from it.” Today Connor made a boat. The friends who helped him were Jarrod and Thomas.

The boat was not very big, but it was very long. It went across the whole room. Connor tells me they used it as a boat, but it actually was a bridge.