On Beauty in Code

I was thinking about the topic of beautiful code this morning. There’s a lot of disagreement about what constitutes beauty in code. I’ve watched Marcel Molina Jr. talk about “Plato and Pythagoras”:molina. O’Reilly has published a “whole book on the subject”:oreilly. On the other hand, “Jeff Atwood thinks that there’s no such thing.”:atwood. I disagree with Jeff on this – I definitely think there is such a thing as beautiful code. But I’m not sure if my idea of what makes code beautiful is the same as others’.

What do I even mean when I say something is “beautiful”, anyway? Beauty is in the eye of the beholder, after all – there is no objective standard. For my purposes, I consider something beautiful when it triggers a certain emotional response. A flower is beautiful because I enjoy the simple act of observing it for its own sake.

!>/images/macbookpro.jpg!

When it comes to functional human-created objects, I’ve noticed that certain properties tend to trigger this emotional reaction. Here are a few products I find beautiful:

* The “Mini Mag-Lite”:maglite
* The “Fisher Bullet Pen”:fisher
* “Chaco Sandals”:chaco
* The “Apple MacBook Pro”:macbook

These are all products which are extroardinarily well engineered for their respective tasks. Out of that engineering emerges a kind of clean, austere beauty. I guess you could say my esthetic runs toward the “Bauhaus school”:bauhaus of thought.

!/images/maglite.jpg!

One of the projects that has recently impressed me as having this property in its code is the “Ramaze”:ramaze web framework. The Ramaze “source code”:ramaze_source is clean, straightforward, well-commented (but not excessively so). Most methods are only a few lines long, and the lines themselves are short. White space is in abundance, setting off stanzas of code. And the logic itself is usually easy to follow.

Routing is traditionally a thorny area in web application frameworks. Here is the Ramaze routing code, in its entirety (minus some documentation):

#          Copyright (c) 2008 Michael Fellinger [email protected]
# All files in this distribution are subject to the terms of the Ruby license.

module Ramaze

  class Route
    trait[:routes] ||= Dictionary.new

    class << self
      # Retrieve key from trait
      def [](key)
        trait[:routes][key]
      end

      # Set key to value in trait
      def []=(key, value)
        trait[:routes][key] = value
      end

      # remove all routes
      def clear
        trait[:routes].clear
      end

      # Resolve path according to routes.
      def resolve(path)
        trait[:routes].each do |key, val|
          if key.is_a?(Regexp)
            if md = path.match(key)
              return val % md.to_a[1..-1]
            end

          elsif val.respond_to?(:call)
            if new_path = val.call(path, Request.current)
              return new_path
            end

          elsif val.is_a?(String)
            return val if path == key

          else
            Log.error "Invalid route #{key} => #{val}"
          end
        end

        nil
      end
    end
  end

  # Shortcut for defining new routes.
  def self.Route(name, &block)
    Route[name] = block
  end
end

There is only one method of any length, @#resolve@. And that method has an easily recognizable cadence – if path matches some predicate, then perform some transformation, and return. Else move on to the next clearly-delineated stanza. This is another quality of beautiful code: each method body has a recognizable, almost archetypal “shape” which is not littered by special cases and digressions.

!