Recently, I wrote a post about an article titled, "Software Engineering for Scientists". One of the strong points made in that article was that
There’s 60 years of existing scientific knowledge buried in code and it’s extremely difficult to extract. As scientists write new code, they need to clearly express intent in a way that doesn’t affect code performance.
This reinforces the idea that there is a huge issue concerning the writing of clear, concise, and understandable code in industry and academics. In light of this idea, I've recently published an article with Henry Ledgard titled "Coding Guidelines: Finding the Art in the Science" that can be found here and here. The article itself is focused on the idea that there is a role that aesthetics plays when writing code. This is perhaps summed up best by the first few lines of the article:
Computer science is both a science and an art. Its scientific aspects range from the theory of computation and algorithmic studies to code design and program architecture. Yet, when it comes time for implementation, there is a combination of artistic flare, nuanced style, and technical prowess that separates good code from great code.
This article, as opposed to those that layout strict coding guidelines to increase performance and maintainability, is focused on developing code that is easier to read by focusing on the aesthetic appeal of the code. And, while it has not been studied yet, code that appeals to developers in this fashion should lead to 1) Easier maintenance, 2) Increased productivity, and 3) A shorter period of acclimation when working with an unfamiliar code base.
In the paper, we present 6 distinct guidelines that should be followed as much is possible:
- Consider a program as a table;
- Let simple English be your guide;
- Rely on context to simplify code;
- Use white space to show structure;
- Let decision structures speak for themselves; and
- Focus on the code, not the comments.
Some of these ideas are controversial and some people will see a few things that we have presented as impractical. That is why we have presented our ideas as "guidelines", not "standards". This is a flexible set of ideas that can be molded to fit individuals and corporations alike.
Beyond this, the use of aesthetics in coding suggests that there are some general principles that will aid in making code appealing to nearly everyone, though there will be some nuances between different developers.
One thing I would like to mention is that some folks have pointed out some errors in the Figures (particularly Figure 1). I would encourage readers not to lose sight of the "forest for the trees" in this situation as requests have been made to fix these minor errors. This is particularly true as the guidelines are intended to be IDE, language, and syntax neutral. Thus, the visual appeal (and the point) of the examples should be apparent regardless.