Code is not Beautiful. Algorithms are Beautiful, Code is Ugly.

As a programmer, I've done a lot of coding over the years. I've come to the realization that most code is ugly. Not ugly enough that I'm repulsed by it, but ugly enough to be called ugly rather than just not pretty. Beautiful code does exist, but it's usually in tiny little snippets and very rare. Ugly is too strong of a four-letter word to describe the majority of code that I have not seen and probably will never see in my lifetime. However, I will use it here for lack of a better, more pronounced term.

Don't take me wrong, I'm not saying it's the formatting that's causing ugly code, I'm saying it's a fundamental property of all programming languages. (Written language to me is ugly as well, but that's for some other time.) The syntax, the grammar, the vocabulary, the keywords, and the punctuation are just so absolutely not beautiful. And...considering the hack-ish code necessary in order to parse and tokenize all that ugly, I really think I'm right to say code is ugly.
Kia Kroas :=: 04 Apr, 2010 06:47:07

I'll admit it, I think my code is ugly as hell. As a coder, I'm not too ashamed because I look at code written by people who have so much more experience than me and people who know so much more than me and I think their code isn't beautiful either. Better than mine no doubt, but still not beautiful. Everyone has their own sense of beauty, and differing levels of what constitutes it. Mine obviously is a very high bar. However, I doubt my rating is different from most other programmers.

When people say 'beautiful code', I believe they actually mean 'elegant code'. The difference is subtle, but the distinction is very important. Beautiful things delightfully pleasure the senses and excitedly satisfies admiration. Code does neither. Elegant things are ingeniously simple, yet finely tuned to be unusually effective at their task without expending extra effort. This is what the hackers--both white hat and black hat--seek. Elegance is what good code displays.

Some will argue that code does delight their intellectual prowess and satisfies, or even surpasses, expectations and admiration. However, I will argue that it is not beauty for the sake of beauty, but rather beauty in the algorithm or process in which it works. Elegance confused as beauty. And if they say elegance is beautiful, then I'll answer with 'to each his own'. There are also a few who confuse the IDE or the editor for the code itself. It isn't.

The IDE is only a means to display the code. Take out the syntax highlighting and fancy fonts. Absent of the facade, can you still tell me that code is beautiful? Syntax highlighting and keyword coloring is makeup; it's a layer of paint and coloring to soothe the eyes of blemishes. Truly beautiful code can stand without it and still mesmerize.

Now keep in mind, not all good code is plainly elegant; a few are so elegant that they verge on eloquence. They forcefully, although sometimes also carefully, command respect through authoritive elegance and efficiency. Of course, bad code screams and yells louder than truly eloquent code, so it takes some skill to differentiate between the two.

Code is very verbose, so eloquence and language fluency are important, even considering how you are allowed to define your own special, reusable words. Code is very much like legal writing. The style is arcane and practically unreadable by those not versed in the art. I bet even linguists who study the language find it difficult to wrap their mind around a few of the documents. Heck, lawyers probably have trouble interpreting their own legalese sometimes.

I refer you to Google's Terms of Service and Facebook's Statement of Rights and Responsibilities, which is just a fancy term for Terms of Services. Notice the blocks of text; they're the legalese equivalent of blocks of code. Google's is nicely indented, very much like python. Facebook's is indented as well, but scattered and the margins are off--very much like what would be expected from PHP. (I'm not looking to start a language war, so I'll stop there). The top section of Google's TOS has some variable declarations in the form of "referred to below" or "referred to collectively". Facebook's SRR lack that efficiency, but it still has quoted declarations inside parenthesis.

There are also links, which could be viewed as a relation or foreign key when viewed as from a declarative language's perspective, as function or routine calls when viewed from an imperative language, or as references to other object when viewed from an object oriented perspective. There are even conditionals such as if-then, when, where, and in order to. Loop definitions are strangely nonexistent; I blame it on the lawyers' attempt at preventing loopholes and infinite argument loops. Too bad that doesn't prevent infinite recursion in the courtroom.

There are base keywords that both use repeatedly, namely 'You will', 'You agree', and 'You understand'. And there are important templates that are reused in both, specifically the part in capitalized text such as the Limitation of Liability. Both documents also try to encompass as much reuse and generalization as possible while still explicitly mentioning the little crevices where bugs or loopholes could arise. So for all their intents and purposes, lawyers write code. There's a reason why laws are referred to as legal codes.

I hope I've proven my point with the similarities between code and legalese--which I believe no one in the right state of mind would like to read (I don't really mean that). But if I haven't, I'll show you some code examples.

For those not convinced, tune in next week when I throw some code examples.