Pretty Code

Way back in the old days when programmers coded using simple text editors and command line editors there was a utility called Pretty Print (or some variation). These utilities would take text files as input and output code that was made more “pretty” and so easy to use. They would add consistent formatting of loops, comments, tab stops and space between keywords, variables and other elements of code. The results looked better when printed. One major benefit of all this is that reading code looking for bugs was a lot easier. I was reminded of this old utility when I read the post “You code like a girl!” which I included in my interesting links post.

Modern IDEs like Visual Studio make consistent formatting much easier than the old text editors did. They even color code things for you so that the difference between reserved words and variable names jump out at you. The obvious effect of all this is that the formatting looks nicer to some definitions of nice. It’s largely superficial as the code would run just as well if the formatting was poor, spacing was inconsistent, and there were no color coding at all. The compiler ignores all of those things of course. And here we start the search for “inner beauty” of code.

This is more complex a question. It also means that one has to be concerned about the difference between clever code and efficient code. Some are impressed by code that is difficult to understand but used as a means of impressing the reader rather than the compiler. Ternary operators and recursion sometimes run the risk of being incorrectly seen as beautiful when in reality they add unnecessary complexity. Though like so many things beauty can be in the eye of the beholder.

I remember a recursive bit of code I once wrote that I just found elegant and cool. No one else in the group agreed with me and I had to rewrite it. It was clever (in my opinion) but it was also unnecessarily hard to understand. Is it really beautiful code of no one else can understand it? Isn’t that the modern art sort of question? But code has to be used, modified, expanded, and understood easily by everyone who views it. Art tends not to have those requirements.

I’m not sure I have a good operational definition of beautiful code. Of course it is formatted nicely. Big deal! Highlight the code in Visual Studio and hit the Ctrl-e, Ctrl-f key sequence and everything will be lined up nicely for you if it is not already. For inner beauty I look for things like names that make sense without being obnoxiously wordy. I look for classes that properly handle public and private access and have clear methods for dealing with data. I look for methods that are not too long as to be hard to follow. I look for code that is as complex as necessary but no more complex. I look for comments that make things clear but don’t hide what is going on. I look for code that looks like it was designed and not patched together by adding semi-random code until things seem to work. I guess I sort of just know it when I see it.

What do you think of as beautiful code? Does it exist in your world few or is it just the ravings of people who are just a little too much geek?

Comments (1)

  1. Alan Kleymeyer says:

    I agree completely with your definition of pretty code.  Pretty (as you define it) == maintainable, expandable, bug free.

    Ugly code == difficult to maintain, buggy, expensive to expand.

    I'm  amazed at how many programmers don't take the time to select good names for things.  They think they are being clever and efficient using 2 or 3 character names for variables.  On more than one occasion I come across variables named to do the OPPOSITE of what they actually did!  I would also define pretty code as code that has been refactored  so that duplicate code does not exist but instead is organized to be easily reused.

Skip to main content