Keeping Code Aesthetics in Perspective
Programmers love to create code, but we show less enthusiasm for maintaining it - particularly when it was written by someone else. This is a narrow view of the lifecycle of code, and leads us to ignore or misunderstand language features which exist not to facilitate code creation, but rather collaboration and maintenance.
Our desire to focus mostly on code creation is understandable. The difficulty of our domain makes constant, intense learning a necessity. This makes it inevitable that we come into contact with badly written code - more often than not written by us, 6 months ago. Inheriting responsibility for maintaining and improving a large codebase written by a novice is one of our worst nightmares. We are accustomed to thinking in terms of "problem solving," and code maintenance can feel like solving the same problem over and over again. Programming is also a creative endeavor, which makes us want to seek a clear end point: Picasso may have done many drafts, but eventually he did finish painting "Guernica."
But programming is not painting, and maintenance is a fundamental part of our profession. The widespread adoption of practices such as Unit Testing indicate an awareness of this fact, though when arguing for such techniques, developers often focus on test-driven development, which describes the value of Unit Testing in the context of code creation.
Our desire to focus on code creation rather than other aspects of our profession can lead to a shallow view of programming language features. Falling in love with syntax aesthetics is one of the most common examples of this.
For example, many C-like languages allow you to omit braces around conditionals:
if (foo)
bar();
Many programmers will advise against such formatting and recommend
if (foo) {
bar();
}
to avoid potentially confusing cases such as this one:
if (false)
this_wont_execute();
but_this_will();
While it may be easy for experienced programmers to avoid creating code like this, it's easy to accidentally introduce such an error during maintenance. Even if you arrogantly assume that you will never insert such an error, the people you collaborate with may. Despite this fact, the brace-free style is still often used by programmers who find it more aesthetically pleasing.
Another recent example of this comes from an article by Mislav Marohnić, in which he defends his preference for leaving semicolons out of Javascript.
Some background on this: when Javascript was created, it was conceived as a programming language for inexperienced programmers to use for small scripts inside web pages. For much of the history of Javascript, this was almost entirely how it was used. The creators of Javascript reasoned that since inexperienced programmers were likely to forget semicolons, the language should try to work without them wherever possible.
Mislav points out that semicolon-free Javascript usually works well, but leaving them out can lead to some cases such as:
a = b + c
(d + e).print()
Which is evaluated, somewhat counterintuitively, as if c were a function:
a = b + c(d + e).print();
He recommends to avoid this by using the following syntax:
a = b + c
;(d + e).print()
I'm not sure if this is a serious recommendation or just a joke, but it does resolve the issue, though at the expense of the aesthetics he's trying to improve.
In this case as well, an experienced coder who knows how Javascript works is unlikely to create such problematic code, but it's fairly easy to imagine how an error could be introduced as a large, complex program is maintained by multiple developers. Like C-style conditional braces, Javascript's semicolons are optional syntax that can be used to make code more foolproof, and therefore more maintainable.
The pleasure we derive from our work is important, and I by no means wish to suggest that we always program to the lowest common denominator. It's perfectly acceptable to make concessions to aesthetics if they increase the enthusiasm you feel for the work you're doing. However, it's important to bear in mind that aesthetic decisions can sometimes have an impact on the long-term maintenance of a program. If you're working on code that will be edited by many developers, remembering this will ultimately allow you to spend more time creating code, and less time maintaining it.
Published