Programmer Musings

Form vs. Style

Ever since O'Reilly published the new book Beautiful Code, there seem to be references everywhere to what makes code beautiful. While a few people have suggested that beauty should not influence code (see the comments section for the suggestion that there is no beautiful code), I believe that most people have seen code that they thought was particularly well done, and might even be considered beautiful.

I suspect that most people focus on the wrong thing when then think of beautiful code. I would like to separate what most people consider beautiful into two parts: form and style. By form, I mean the fundamental design or structure of the code.

• Does it solve the problem at hand?
• Is it understandable?
• Is it as simple as possible, but no simpler?
• etc.

On the other hand, style refers more to issues that may be important, but are less fundamental.

• Does it follow the coding guidelines of the group?
• Is it written in the appropriate language?
• Is it a clever or cool solution?
• etc.

Many people focus too much on style at the expense of form. I think that is partly because style is easier to codify than form. Almost anyone can enforce a brace style or naming convention, but making or recognizing a simple solution is much harder. Programmers are also attracted to complexity and are often seduced by clever solutions.

The real downside is that people often try to fix a bad form by piling on more style. This never generates a beautiful solution, but it might obscure the extent of the bad form. Like the fins on a 1950's Cadillac, it looks cool now, but it won't look as good later.

Ugly Code

I don't usually write beautiful code. I do focus hard on the form, but I am rarely completely happy with my solutions. Despite this, I feel I have some advantage in this area. Early in my career, I was exposed to quite a bit of atrocious code. This code depended heavily on global variables, misused language idioms, and preserved old code mistakes as running comments in the code. It was hard to read and difficult to maintain.

This code formed the basis of my desire to improve, I never want to leave behind code like that. Over the years that followed, I tried to hone my skills at recognizing what I called good code.

Beautiful Code

At one point, I was working with a promising young programmer on a redesign of an important part of the system we were maintaining. We had spent time discussing the requirements and had mostly worked out the general shape of the solution we would use. At that point, I needed to leave for the day and we agreed to work on it some more the next day. I came in early the next morning and took a look at the code. She had laid out the beginnings of the code without filling in all of the details. Each major piece of functionality had its own well-named function. Higher level functionality was built in terms of the lower level pieces. Every function had a clear name that explained the function's responsibility. The general gist of the design was already in place with placeholders for anything that we had not had a chance to work out.

This was by far the most beautiful code I had ever seen. I actually dragged another senior programmer over to see this code. The style was not yet perfect, There were many levels of stuff that could have been added on top of this code. But, the form of the solution would have been obvious to anyone seeing the code. As we worked over the next few weeks, we did make some comprises that marred the initial beauty of the code and we layered on some style to make the result a bit prettier. In the end, the original beauty remained mostly intact and visible.

Evaluating Code

I've used that code as my yardstick ever since. I may not write beautiful code every time, but I have good examples of beautiful and ugly code in mind that serve as my guides. As I write code, I try to evaluate my code against those examples.