Guidelines for Coding Aesthetics

What makes code truly beautiful? Is there something more to it than just instructions executed by the machine? Is there an absolute reason for its beauty or is it merely biased opinion? Is it the underlining algorithms that make code beautiful or is it the organization of the code itself? Where do you draw the line and say that some code is ugly, some code is normal, and some is magnificent(Okay, more like lines - plural)?

I believe that these questions all have answers. Which is really the objective of this blog. To seek out new ideas and beautification...to boldly go where every software engineer should have gone before..that is to the depths of the coding practice and the ideas behind what can make software so solid it won't collapse even with the most treacherous hammering which true software testers provide.

I want to take a look at each question to truly define the guidelines behind coding aesthetics - in otherwords what makes code truly beautiful(Thus answering the first question). I first want to address the question about algorithms vs. code organization. This happens to be a deep subject for me and thus may take a couple of posts. Hopefully, I'll address how I feel about algorithms in this blog. The other questions I plan to cover in another post but remember that this is discovery. SO I'm glad to say I don't have all the answers yet :).


Efficient Algorithms vs Code Organization - Which one is beautiful?

At any university level Beginning Algorithms course it should be taught that every algorithm runs at a certain order of magnitude based on some sort of notation. The most common notation is the "Big-O" notation since it is used to determine the worst case scenario of a running algorithm and thus makes for an excellent candidate for measuring the overall efficiency of any given algorithm. While there are many details behind the use of other notations this is the only one I will consider here. However, my point being that efficiency is very important for the machine to run quickly and you might even call it beautifully...since it is beautiful to have a process finish in a short period of time. Unless of course you like your software to freeze while you make coffee or something...

Anyway, the "Big-O" notation has rules which can be placed on common coding mechanisms (assignment statements, loops, control structures, functions...etc). The point being that with these types of statements there is a cost on the system and it doesn't matter what the notation is...you must take into account the overall effect of the algorithm to understand how efficient your code is running. This means that the "Big-O" notation, regardless of all the system specifications - how fast it runs - how much space is available, measures the algorithm the same as to NOT take into account any details of the system.

This really measures efficiency in a way that is more geared toward any hypotetical system. Great huh? So what does this have to do with beauty in code - the efficient algorithms that are measured regardless of system details are in effect beautiful because they can be implemented on any system and work the same (Only vary in systems specific speed).

There is however a drawback to the idea behind efficient algorithms! They sometimes contain some of the most incomprehensible code which requires several days of labor in understanding as well as planning. The problem isn't that they are hard to understand but can create truly unorganized messes that can only be read by the original author...no matter how efficient it could seem to run..the maintainers hate the software and hope to never venture into the land of algorithmic chaos. Yep..that really does happen in the field.

So, there is an obvious beauty to organization. Which I believe is based on coding standards and styles. More of this is to come in the next post..but just to recap - Efficient Algorithms are beautiful in the since that they can run beautifully and have ingenious components that make them worth while to understand but the can cause an overwhelming difficulty in organization. My point is that beauty isn't in the algorithm itself - or the idea ALONE! Beauty is found in more than one place. Of course, you could say its in the eye of the beholder..but then you would just be irrational. :)