Category: Thoughts

Defining readable code

Code readability is something that I often bring up during code reviews, but I often have trouble explaining why I find a piece of code to be easy or difficult to read.

When you ask programmers how to make code easier to read, many of them will mention things like coding standards, descriptive naming, and decomposition. These things actually aid in making code easier to comprehend rather than easier to read. For me, readability is at a lower level, somewhere between legibility and comprehension.

At the lowest level is legibility. This is how easily individual characters can be distinguished from each other, and can usually be boiled down to the choice of font, as well as the foreground & background colours.

Dishonest comments

One of my favourite Ruby Rogues episodes (What Makes Beautiful Code) has a short section where the Rogues talk about the concept of dishonest code. David Brady wrote a really good piece on this, which I highly recommend reading.

What I want to talk about is a more specific variant of dishonest code: dishonest comments.

Take this code, for example:

$('a').click(function(e) {
    e.stopPropagation();
    e.preventDefault();
});

If you’re not familiar with JavaScript events, e.stopPropagation() will stop this event from bubbling up to other event handlers. Now, what if somebody decides that the event should bubble up? They might do something like this:

--- a/example.js
+++ b/example.js
@@ -1,4 +1,4 @@
 $('a').click(function(e) {
+    // Let the event bubble up to the next handler
-    e.stopPropagation();
     e.preventDefault();
 });

This is pretty common practice; a developer will leave a comment so that the next person understands why the e.stopPropagation() is gone.

When did dependency management get so complicated?

This evening I wanted to start hacking on a project of mine, which is a simple WordPress theme. My main development machine was being used by somebody else, so I decided to boot up my old Sony Vaio running Ubuntu. It’ll be simple, I thought. I’ve just got to clone the repo, run npm install, bower install, and grunt build, and I’ll be good to go. I was wrong.

First, the version of npm installed on the laptop is apparently so out-of-date that it can’t run the install. So I let it update itself (and all the other packages I have installed - why not?) with sudo npm -g update. Being a Sunday night, my broadband connection is running spectacularly slow, so the update process takes about 10 minutes at 40kB/s. But hey, at least now I can run npm install, right?

Nope. Now npm is throwing some errors with unhelpful messages, but that’s fine, I’ll just trawl through the error log. 5 minutes later, I figure out that ~/tmp belongs to root (probably from running npm update as root). OK, fine, I’ll change the permissions and try again. This time npm install works! But of course, my connection is so horribly slow and grunt has so many dependencies that the install process takes over 15 minutes.

September 4: Looking back on the Christchurch earthquakes

In the early hours of 4 September 2010, I was sound asleep in my house on Mount Pleasant hill in Christchurch, New Zealand. At 4:35am I was woken by a deep rumbling sound. Seconds later, the floor and walls began to shake as my house was rocked back and forth on its foundations. I scrambled out of bed and hid in a doorway until the shaking stopped. After checking that my family was okay, I went upstairs and stepped onto the balcony to look out over Christchurch. The city was silent save for a few car alarms, and it was in this relative quiet that I came to understand the significance of this event. I didn’t realise it then, but that earthquake would become a catalyst for change in my life.