picture home | pixelblog | qt_tools

omino code blog

We need code. Lots of code.

Well, I’ve been holed up in my dank apartment these last 3 weeks, canvas and plastic stapled over all the windows. I’ve been writing furiously. Red-pencil scribbles cover tablet after yellow Big Chief writing tablet with my profound wisdom and observations. I feel myself following in a great tradition… Dear reader, allow me to share with you some morsels which you might find entertaining or even informative. This is to be the first of a three part epic on the subject of Bad Code.

What makes “Bad Code”? I feel like I’m tormented and dogged by Bad Code. Some of it is my own. Naturally I’m less bothered b my own Bad Code than my other people’s bad code, because I have at least some insight into the perverse intent of the code when it’s my own. But it’s still Bad Code.

What makes Bad Code?

Oh, there’s endless modern kid-stuff about good practices and code smell and all that nonsense. It’s my experience that even good kids who learn all about test-driven development and favoring composition over inheritance and all that rubbish and follow it to the letter still write Bad Code.

What makes Bad Code bad?

First of all, it has to be code. You wouldn’t call it Bad Code if you experience it as an application or tool or whatever. You’d call it a bad app, or a bad web page. I’m talking about Bad Code. You typically experience code in the form of a library that you want to use or source code that you’re called upon to modify.

Here’s my definition of Bad Code: If you can’t load it into your IDE and make it do something interesting under your control in twenty minutes, it’s Bad Code.

Let me justify this first with a counterexample of some Good Code. Oh yes. Cranky am I, but praise is possible.

Some Good Code
One of Mozilla’s open source projects is Rhino, a JavaScript interpreter. (Actually it is officially called ECMAScript now, but whatever.) Why is this Good Code? Let me count the ways:

  1. It’s easy to find: http://mozilla.org/rhino/.
  2. It was easy to download. A full source drop was 1.7M.
  3. Although it wasn’t an Eclipse project, it imported perfectly into Eclipse as a “Java Project from Existing Source” with almost no errors. A fast look reveals that all the errors are in one package implementing XML stuff, and its referring to org.apache.xmlbeans. On a whim, I remove that entire subpackage and apparently nothing else was depending on it.
  4. There is clearly marked “examples” directory…
  5. The examples are named, have a few comments which are enough to get the lay of the land.
  6. I create a blank .java file, and start copying bits and pieces from the example into my new file. Soon, I have a tiny piece of code which I think I understand pretty well, and does something explicable

Here’s some code. I know it’s a bother, but give it a read. It’s short. It would mean a lot to me. And remember — it took me less than 20 minutes to get here.

public class DvbScript {
    public static void main(String args[])
        Context cx = Context.enter();
        try {
            Scriptable scope = cx.initStandardObjects();
            String s;

            s = "var abc = 13/7;";

            s = "var xyz = Math.sin(1.33) + "*****";";
            Object abc = scope.get("abc",null);
            Object xyz = scope.get("xyz",null);
            System.out.println("abc is " + abc.toString() + " and is a " + abc.getClass().getName());
            System.out.println("xyz is " + xyz.toString() + " and is a " + xyz.getClass().getName());
        } finally {
Produced this output: abc is 1.8571428571428572 and is a java.lang.Double xyz is 0.9711483779210446***** and is a java.lang.String

In that brief bit of code, I managed to successfully exercise the library and begin to understand the internal scheme of the interpreter.

Why It Was Good
It wasn’t a completely bump-free ride. I had to slice out part of the source code as downloaded… I deleted a whole lobe of the source tree that appeared to be all about XMLBeans or some such. But it was painless. Their one dubious external dependency on org.apache.* was isolated and optional.

The examples were easy to find, and they ran. At first they produced exceptions, but then I read the source code comments and knew what to pass on the command-line and all was well.

Fundamentally, as a user of this library, this Good Code, I felt like I was the target audience. Someone had considered that I would be sitting here today trying to run their stuff.

Now, here’s the thing of it: Bad Code feels the same way. It feels like someone has consciously considered that I, David Van Brink, would one day try to use their stuff, and has premeditated ingenious ways to thwart that goal.

In part two I’ll be cheerfully exposing some of the strategies that Bad Code takes to torment me.

oh, i dont know. what do you think?

(c) 2003-2011 omino.com / contact poly@omino.com