Monday, January 24, 2011

Code = bugs

I've come to the conclusion that all code is buggy, often hideously so.

This isn't necessarily an observation on other people's code. My code is perfect. Ha! Only it's not, of course.

Something like JKstat is reasonably mature and (I thought) reasonably well tested. But the latest release fixes a number of pretty basic numbskull bugs that had been sitting there for ages.

I place a lot of emphasis on code quality. I use jstyle (part of the Solaris ON build environment) to enforce a programming style. Enforcing consistency makes the code more readable, and this style is one that my eyes (and my typing fingers) are comfortable with. I use PMD to automatically check for basic errors and obvious code deficiencies. When I first started using PMD, it found lots of basic errors. What it doesn't catch are the doofus logic errors that my brain introduces.

For Java programming, I found Generics to be a great benefit. Java is a strongly typed language, but a major structural part of the language - the Collections framework - didn't impose any type safety at all. Everything was just an untyped Object. Whilst Generics adds type-safety, and the enhanced for-loop often precisely expresses your intentions (as opposed to looping over an array index), I found that adding Generics made be think about the types of object I was putting in my collections, which was one step in thinking more about the structure of the code itself.

Occasionally, I get to look at code written by others. Now, often, open source code isn't actually too bad - there's often a fixed style adopted by a community, and multiple authors can eliminate some of the more bizarre excursions into code obfuscation. But some of the code I get to see in the office truly horrifies me. Invariably without useful comments, with all the old code still in the source file but inactive, and as many different styles as we've had people work on the code (often in a language they're not entirely fluent in), just hacked in to the point where it would work with no attempt (because there's no money in this) to go back and improve maintainability of the code for the next person.

One of the problems is the languages themselves. Java is strongly typed (I like this, because it makes simple typing errors into compile failures which are obvious), but requires massive levels of boilerplate. I dislike the use of an IDE, because I want to feel comfortable with every line of code I write. So you're wedged in to a place where just feeding the IDE, or writing boilerplate code, takes far too many brain cycles away from actually implementing real functionality.

So change languages, you say! Well, I actually try and learn one new language (or a major area of a language) each year. So I wrote a monitoring application in tcl/tk once, then rewrote it as a webapp using JSP, then rewrote it to do graphics using Java2D, and then rewrote it in PHP, just so I could learn those languages. After several attempts, though, I have completely failed to acquire any significant competence in Python.

Something I have been looking at recently (after an excellent talk at the local Cambridge Java Meetup group) is Clojure. You may find this a bit of an odd choice, but hacking on lisp for emacs many years ago makes it moderately familiar, and being built on the JVM means that I may be able to leverage other skills.

Which leads to a question: what programming language (or skill) have you learnt this year?

New year, new JKstat

I've been quietly working on JKstat, and have just released another update, version 0.43.

I wasn't actually aiming to cut a release at this point, there are still a couple of things I'm working on. But I needed to get some fixes into KAR, and didn't want to push out a KAR release with an unreleased version of JKstat in it, hence a synchronization release.

Realistically, JKstat has largely stabilized. So it's more a case of fixing odd bugs (the network load demo wouldn't display anything if you resized it, and guessed the network speed wrong), adding features like stepping backwards in the browser when reading KAR data, and cleaning up the javadoc. Little features like keeping all the statistics underneath a chart, so that when you add another statistic to be graphed it shows the historical data rather than starting from the current time. Nothing earth-shattering, but (hopefully) making JKstat better.