Elegance is Not Optional

I have an old book (1994) on Prolog called The Craft of Prolog written by Richard A. O'keefe (MIT Press). One of the crucial 'values' of the book is that "Elegance in Not Optional". I find this to be a very striking statement, as I have always felt that design suffered under the realities of practical use. Application performance always seems to ruin a program. It may be that Prolog, because it runs in a isolated workspace has the pleasure of elegance. There are no nasty operating systems or databases to deal with. Yet, I am still drawn to this vision, I want to believe. I have added a small quotation from the text.

Elegance is not optional (1)

What do I mean by that? I mean that in Prolog, as in most halfway decent programming languages, there is no tension between writing a beautiful program and writing an efficient program. If your Prolog code is ugly, the chances are that you either don't understand your problem or you don't understand your programming language, and in neither case does your code stand much chance of being efficient. In order to ensure that your program is efficient, you need to know what it is doing, and if your code is ugly, you will find it hard to analyse. (The Craft of Prolog, Richard A. O'keefe, MIT Press 1994)

I believe that a developer should strive for readability first and foremost. Most of the guidance in Code Complete (Steve McConnell, Microsoft Press) is aimed at improving code readability. I would even go so far as to say readability first, function second. You can always debug a readable program and make it right. But a mess of code that works might as well not exist since any changes to it probably mean rewriting it anyway.

Readability is About Design

Comments, documents, unit tests, all of these things merely support readability and understandability. In the way that a textbook supports a professor. The professor must still be able to teach and must stand on their own with or without the text to be truly effective. Such is also true with code. It should make sense without the supporting pieces, since so often these pieces fall into disrepair. Code is never 100% covered by tests. Comments are usually sparse, out of date or poorly written, as with documentation. The organization and naming in the code must point to its intent and function. The code expresses the solution, it doesn't just implement it. This should be the developers prime concern, express the problem and its solution with the program itself.

Elegant Design

What is elegance? Have you ever heard the expression 'Form follows function'? Everything in the system must have a good reason for being there. Nothing is superfluous, there is no programmer ego, or 'interesting' technology, or 'feats' in the code. The code should read like a well written technical document. Step by step to a predicatible ending. Detail at each level is consistent, methods and data are grouped logically. Nothing is out of place or mysterious. Design also subscribes to the expression 'Function follows form' whereby choosing an elegant form results in a superior design. This implies an intuitive element to coding where you can't just apply rules and refactorings. If it looks good it probably is good.

If you understand the problem, you should be able to look at the solution and say ahhh... yes, I see.