Monday, June 1, 2009

Code Beauty is in the Eye of the Beholder

The phrase beauty is in the eye of the beholder is often used to describe the wide variety of peoples' opinions of what is beautiful. Although this phrase is commonly used in describing different perceptions on the appearance of a particular person, it definitely fits the concept of beautiful code. In this blog posting, I'll look at how some of the subtleties surrounding the rather subjective measurement of human beauty apply to the equally subjective measurement of code beauty.

It is nearly impossible to quantify whether a given individual is beautiful or not for a wide variety of reasons. Does "beautiful" refer only to physical appearance or does it include personality, intelligence, communication skills, social graces, and so forth? Is beauty an absolute or is it more relative (rather than saying someone is beautiful and someone else is not beautiful, is it easier to say the first someone is more beautiful than the next someone)? The aspects of a person's appearance that are important to one person's perception of beauty may not be as important to another person's perception of beauty. All of these considerations impact our ability to gauge code beauty as well.


The Beauty Spectrum

When it comes to deciding whether a person is beautiful or not, there seems to be a spectrum of people. On one end, there are individuals who nearly everyone would agree are beautiful. For example, I don't think many people disagreed when Michelle Pfeiffer was named one of the 50 most beautiful people in the 1990 People Magazine edition. On the other end, there are a few individuals who almost nobody would argue are beautiful. Most people are somewhere in between where there is a split of opinion on whether or not they are beautiful.

Code beauty works in the same way. There are some samples of code that nearly every developer would agree are beautiful (as far as code goes), there are samples of code that developers would nearly unanimously agree are anything but beautiful, and there is a lot of code in between in which developers will disagree on whether that code is beautiful or not. Because so much code falls somewhere on the spectrum other than the extremes (obvious beauty or obvious ugliness), it can be difficult to get agreement on what constitutes code beauty in these cases.

I see examples of this disagreement about code beauty on almost a daily basis. I find myself increasingly fond of less code and approaches such as Java's ternary operator. I see beauty in conciseness. However, I know several experienced Java developers that loath the ternary operator. I noticed in the JRuby Code Conventions that there is an emphatic note: "Do not, never, I repeat, never, use something like 'if (expr == true)'." Although I generally agree with this, I know people who honestly prefer the explicit true or false comparison.

Then of course, as one of many other examples, there is the whole issue of where to place the curly braces (or even if we should have curly braces at all). There is also the debate over level of commenting. Some think no comments make the most beautiful code, others think very verbose commenting is gorgeous, and many others are somewhere in between. For me, I like concise code, significant white space, carefully chosen comments, highly descriptive method names, and so forth. However, I know many respected developers who have differences of opinion on each of these attributes of code beauty.

Even my own sense of code beauty has changed over the years. When I first read about the enhanced for loop that was anticipated for J2SE 5, I did not particularly like how the code looked. However, it has grown on me and I really, really like the conciseness of that loop and wish that it could be used for an even wider set of iterations. Similarly, I used to be one of those who detested the ternary operator, though I deeply appreciate it in the right context now.

With so many different ideas of what is beautiful and even our own changing ideas of what is beautiful, it is difficult to classify many pieces of code as beautiful or not beautiful in any absolute sense of the word.


Code Beauty is More than Skin Deep?

When I was in high school, my mom and I had very different ideas of what made a girl beautiful. I nearly completely focused on physical looks while my mom was more interested in trying to get me interested in girls who had more than just good looks. I have since learned that beauty really is more than just the outside appearance (although it still includes it along with the other aspects).

Code works the same way. The best code cannot make up for poor design. In fact, many argue that "beautiful code" really does not pertain to the superficial appearance of code and instead really references deeper things like good design, loose coupling, modularity, and so forth. One of the several authors of Beautiful Code has also pointed out (related to recursion specifically) that beautiful code can sometimes actually be less efficient or even not work as well as less beautiful code. Jonathan Edwards has pointed out something that I have experienced myself: like physical beauty, code/design beauty is often marred by life as realities, compromises, and special cases creep in.


Can Code Really Be Beautiful?

In Code Isn't Beautiful, Jeff Atwood argues that code is not beautiful. He has a point. It is difficult to argue that code can be "beautiful" in the same sense as a sunset, a snow-covered mountain top, an ocean or beach, a tropical paradise, and so forth.

As discussed in the spectrum topic above, I definitely believe that some code is more beautiful than other code. However, I try not to get too worked up about striving for "beauty" at all costs because working and useful code can only be beautiful to a point. Code is not only about art and beauty; it is also about functionality.


Conclusion

Proponents of certain languages or frameworks will often tout the beauty of that language or framework. Unless there is significant explanation of why and what is so beautiful about it, I generally dismiss these types of statements as irrelevant. Without further explanation, to say "that particular code is beautiful" is akin to saying "I personally think that particular code is beautiful." That's fine, but that doesn't mean that others, including those who will be maintaining that code, feel the same way. After all, code beauty, like all types of beauty, is in the eye of the beholder.

5 comments:

alexandroid said...

I am sure, same as for physical beauty, one could come up with pretty reasonable criteria about code beauty which would allow at least comparison if not ranking the code.

For code such criteria could be "how readable is it". It is hard to measure, but I am pretty sure it could be done by giving same piece of code to 100 people and ask them to find a bug, or update the functionality.

There will be correlation with "code beauty" and time which those people spend on doing the task. Change "aspects of the beauty": design, formatting, naming conventions - and you should notice how your statistics change. Of course, there will be compromises between beauty and performance etc, but it does not make code beauty an invalid concept.

Sure, people's ability to learn and to read the code depend on their habits and experience, but after all we are all human with similar eyes and brains. Cognitive psychology is still there and working.

So, dismissing the problem to "the eye of the beholder" does not seem to be entirely fair. If the code is maintained by same group of people, they should define what is considered to be beautiful. And demand others to follow that standard. As code owners change, code will gradually change with them.

Dustin said...

Alexander,

Thanks for taking the time to provide such a detailed response with valid arguments. I agree with most of your discussion, but not the final conclusions.

For example, I agree that it is extremely difficult (impossible) to measure "how readable" something is. Your stated approach is about as good as anything I could come up with, but that type of analysis and collection of input would be extremely expensive. I'd go so far as to say prohibitively expensive. There may be a theoretical approach to gauging code beauty, but it would come at enormous cost and I doubt the value would be worth the price. Furthermore, there would likely still be a relatively large fraction of the population who didn't fully agree with the consensus.

I'll use a simple but powerful example: curly braces in Java. I am on the side that prefers my braces lined up in the same column (Allman/East Coast) for easy visual association of the beginning and end of the block. To me, that is beautiful (relatively). The other popular style (Kernighan and Ritchie [K&R]), to me, is hideous (absolutely). However, many developers who I deeply respect prefer the latter style. Other examples include my love of the Java conditional ternary operator, which some others loathe and consider an abomination.

If something so seemingly simple can be "ugly" to one and "beautiful" to another, it seems difficult to come up with agreement on other more substantial things. I realize that "code beauty" is often as much or more about code design than it is about syntax, but I think design is even more open to interpretation and opinion than syntax is. Some love the singleton; others hate it. I'd like to say that most of us generally consider simplicity more beautiful than complexity, but even that is suspect when one considers that Simplicity is Complicated.

I do think it would be easier to agree on what's ugly rather than on what's beautiful.

Although I stand by my assertion that much of what constitutes "code beauty" remains in the eye of the beholder, I do think that there are things that most developers would generally consider more attractive. That's where coding standards and design standards can help guide the way. But in the end, code, like prose, is somewhat subjective. Just as there are many different style guides claiming to state what prose style should be, there will be and are many different experts claiming that certain, often contradictory, things make code beautiful.

Thanks again for taking the time to provide such an articulate response.

Dustin

alexandroid said...

Well, the answer lies in your comment, and it is aligned with my point(s) -- for many issues it does not matter what choice developers make. For readability sake (my suggested criteria of "beauty") it is the *consistency* of that choice what makes it work. And it must be the choice of a team of developers working on the same module/area etc.

People adjust their taste and become more productive. I like curly braces aligned, but if I read the code where everything is using other convention, I quickly adjust and feel comfortable enough. If the code was a mix of styles, then it would become more difficult to follow.

Same goes with the consistency of design (think patterns), naming conventions etc.

To make it clear again (on the example of the code style): if we do not know what code style works better with human nature, if we think it is hard and expensive to measure, -- it does not mean that answer does not exist or not worth pursuing. But for some things we may not need proof at all, since the intuitive answer seem good enough.

For example, one of those things is the claim that *consistency* improves code beauty and makes it easier to work with.

PS: Another proof of "adjustability" - even with physical beauty we adjust our standards if we change our environment e.g. like move to another country...

Dustin said...

Alexander,

As before, I don't disagree with most of your points, but I do disagree with the conclusion. All of the things you mention do improve efficiency (which can be measured more objectively), but that doesn't mean they are beautiful (a much more subjective measurement).

I'm a believer in standards, coding conventions, best practices, and other industry-proven guidelines for the efficiencies they can bring. However, even when I've used a convention I don't like for years, it doesn't mean that I ever grow fond of it. Instead, I use it because I understand the value of doing so, not because I think its the most attractive presentation. In other words, I value its utilitarianism despite its lack of "beauty." When I move to a new project with standards more my liking, I welcome their return.

For me, the very word "beauty" implies subjectivity. If we replaced the word "beauty" with "efficiency" or "maintainability" or "readability," then I can agree completely with your points.

Thanks again for the discussion.

Dustin said...

Two online resources related to this post that I found interesting are How do you define elegant code? and Clean Code is Beautiful Code.

The former reference has a funny but not entirely untrue comment ("I know it when I see it.") and the second has this insightful comment: "Beautiful Code is in the eye of the beholder. Clean Code has objective standards that make it easier to debug and expand."