Beauty Is In The Eye Of The Beholder
Beauty is in the Eye of the Beholder describes the diverse opinions people have about what is beautiful. This phrase may be used to describe different perceptions of the appearance of an individual, but it is also a good fit for beauty. This blog post will examine how the subjective nature of measuring human beauty can be applied to the subjective measurement of beauty.
There are many reasons why it is difficult to determine whether an individual is beautiful. Does “beautiful’ refer to only physical appearance, or does it also include intelligence, communication skills, social graces, and so on? Is beauty absolute or relative? (Instead of saying that someone is beautiful while another is not, is it easier to say the first person is more attractive?) Aspects of a person’s appearance which are important for one person may not be important to another. All of these factors affect our ability to judge code beauty.
The Beauty Spectrum
There seem to be different beautiful people. On the one hand, there are people who almost everyone agrees are beautiful. In 1990, People Magazine named Michelle Pfeiffer as one of the fifty most beautiful people. I doubt many people would disagree. There are also some individuals that almost no one would consider attractive. The majority of people fall somewhere between the two extremes, where there are differing opinions on whether they are considered beautiful.
The same is true for code beauty. Some samples of code are considered beautiful by almost all developers. Other examples are considered ugly. There is also a large amount of code between the two extremes that is not deemed attractive. It can be hard to agree on code beauty when so much of it falls between the extremes.
This disagreement over code beauty is something I see almost every day. I am becoming more and more fond of approaches like Java’s ternary operators. I find beauty in simplicity. The ternary operator is a blight on the Java world. In the JRuby Code Conventions, there is a note that says: “Never, ever, I repeat never use something like (expr == false )’.” While I agree with the general idea, I have met people who prefer to use an explicit true/false comparison.
As one example, we have the issue. Where should the curly brackets be placed? (Or even if curly brackets are needed at all?) The level of commenting is another issue. Many people think that no comments make the best code. Others believe that very verbose comments are beautiful. I prefer concise code, white space, well-chosen words, highly descriptive method names, etc. I also know that many developers have different opinions on these aspects of code beauty.
Even my sense of beauty in code has evolved. I was not a fan of the enhanced loop when I first saw it in the J2SE5. It has become my favorite loop. I love the simplicity and would like to use it for a wider range of iterations. I was also one of the people who hated the ternary operators, but now I appreciate them in the right context.
It is hard to categorize many pieces of code in a strict sense as beautiful or not.
Beauty is more than skin deep
My mom and I both had different views on what makes a girl beautiful when I was in high school. My mom wanted to make me more interested in girls with more than good looks. Since then, I’ve learned that beauty is much more than physical appearance.
The same is true for code. The best code cannot compensate for poor design. Many argue that the “beautiful” principle is not just about the appearance of the code but also includes things like loose coupling, modularity, and good design. Has been used by one of the authors to point out that beautiful code may not always be as efficient as less attractive code. Jonathan Edwards points out a thing that I’ve experienced: code/design beauty can be marred by reality, compromises, and special cases.
Can Code Be Beautiful
In The Code Isn’t Beautiful, Jeff Atwood argues code isn’t beautiful. He’s got a point. It’s hard to argue principle is “beautiful” in the same way as a sunrise, a mountaintop covered with snow, an ocean, a beach, a tropical paradise, and so on.
I believe, as discussed in the topic of spectrum above that some code is better than others. But I don’t want to be too obsessed with “beauty” because useful and working principles can only have a certain level of beauty. It is not just about beauty and art but also functionality.
Conclusion
Many times, proponents of a certain language or framework will praise the beauty of their chosen framework or language. These statements are irrelevant unless there is a good explanation as to why it is so beautiful. To say that “that code is beautiful” without further explanation is the same as saying, “I find this code beautiful.” It’s okay to think that way, but it doesn’t mean others will feel the same, even those who are responsible for maintaining the code. Code beauty is subjective, just like any other type of beauty.
