The Importance of Clarity

I recently came across an interesting blog: Joel On Software. One post from way back in 2000 discusses the age-old dilemma of when to rewrite code, and has this to say:

The reason that they think the old code is a mess is because of a cardinal, fundamental law of programming:

It’s harder to read code than to write it.

This is so true, despite the fact that, all programming situations, we spend far more time reading code than we do writing it. It doesn't matter whether you are writing a totally new, greenfield program, or simply trying to fix a bug in an old one. You can't work out how the change or extend a program until you understand what it's already doing.

This is so obvious that it's hardly worth stating. It has a corollary which is not quite so obvious, however:

A programmer's most important task is to write code that's easy to read.

You might argue that it's more important to write code that works, but I disagree. The reason is that if you write code that's easy to read, you'll be able to fix the bugs, and so you'll be able to deliver working software. If you write code that's hard to read, you can guarantee that it will have bugs in it that you can't fix.

Hopefully you don't have too much difficulty reading code you wrote this morning. That's one reason why writing unit tests is such a good idea: you discover the bugs while the code is still fresh in your mind. But despite all the unit testing, you will still need to change that code next week, or next year. If you want to be able to do that successfully, you'd better make sure you can still read today's code, whether it's next month or next year.

It's also inevitable that someone else will have to read your code. Making your code understandable by someone else is hard work. Coding conventions are no substitute for thought; you must look critically at what you've written, and ask yourself: have I made it completely obvious what's going on here? If you haven't, then you should fix it.

Many other programming principles are extensions of this one. For example, it's a good idea to write Java classes that are responsible for one thing, and one thing only. If you follow this principle, you're on your way to writing readable code. But blindly following principles is not enough. You have to keep asking the vital question: is this readable, not only by me, today, but also by me in six months' time, and also by the newly-hired junior programmer straight out of university in two years' time?

The effort to write readable code never stops, but it's the most important thing we do.

Applet Jazz

Remember the early days of Java? Remember how the "write once, run anywhere" used to include running on a user's desktop, in the user's browser, until the big bust-up between Sun and Microsoft put a stop to all that? Before AJAX came along, applets used to be the coolest thing on the block at least as far as building webpages that looked a bit special. After the split, though, that all went away. "No-one wants applets" has been the refrain for several years now. Even Sun put applet development on the back burner, while concentrating on server-side Java with a bit of Swing on the side. There has been no real development of applet support since about 2001.

Well, all that may be about to change. With Java FX, Sun is aiming to product a platform for advanced graphics to compete with Flash and Microsoft's Silverlight. One thing that they are keeping rather quiet about is the delivery vehicle for an application written in this new language. It's applet technology. When you build a fancy display tool in Java FX, it's compiled and built into an applet. When you include it in a web page, your user must have Java installed before it will run. The big hope is that this won't put too many people off. After all, Flash sites require their users to install a browser plug-in, and Java won't be any different. Sun are clearly aware of the problem, and the latest version of Java includes various new features to make this installation process faster and more reliable. The question is, will this be enough? Is the installation process reliable enough, and does the platform offer enough features, to tempt web developers into using it?

For the installation process, I simply don't know whether most users will find it acceptable. All we can do is to assume that Sun will do enough, or have done enough, to convince developers that it's going to work. Taking that as a given, let's look at some other problem areas that my recent experience in building an applet has shown up:

1. my applet had to be part of a very dynamic web page which used a lot of Javascript. In particular, some data had to be shown as overlays. This a very common Web 2.0 technique, but it causes problems, because some browsers will not display ordinary HTML elements over an applet. In many cases an IFRAME will do the trick, but not all. We had to resort to some browser-specific Javascript shenanigans to get it to work properly in various browsers, which is something we normally try very hard to avoid.
2. the applet does graphics its own way, without using HTML and CSS. In some ways this is a good thing; if applets can't do more than HTML and CSS, what's the point? The issue here is that we've built up a lot of expertise in working with these tools. A designer produces a static picture in Photoshop, and we know how to convert that into a dynamic web page with styling that can adapt as the content changes. If we do that for most of the pages on a site, and we want to create an applet that has a similar visual style, then we have to re-implement the look in a completely different way. When it gets a re-design, we can't simply change a few stylesheets; the applet has to be re-programmed. I haven't got a good answer is to this one, but it clearly needs to be addressed. The web has moved on since applets were first thought of, but applets haven't moved with it.
3. on a related issue, the support for displaying HTML inside an applet is very poor. It uses an old version of HTML, and doesn't seem to support CSS at all. This is simply not acceptable.
4. in Flash, you can download and use a font without needing to install it in the user's system. That's a really significant feature. In Java, you can offer the user the chance to install a font, but that creates an annoying dialog, and if they aren't an administrator on the machine, they can't do it anyway! If Flash can do this, why can't Java?

I dearly wish that Sun would fix the problems, and make applets into a viable technology again. I've tried programming in Javascript, and I hate it! It's OK for simple things, but as soon as it gets at all complicated, it becomes very difficult to write and debug. Wouldn't it be great to be able to program Web 2.1 in Java?