You probably know this feeling: You take a look at somebody’s code and immediately think “Oh my god this is ugly” More seldom, yet it also happens that you think “man this looks nice” even before you have the slightest idea of what the code is all about.

I hereby claim that the chance of your code being beautiful rises when you apply four principles which origin from graphical design. And with beautiful I’m not referring to some pure aesthetic value but the attribute that is considered an important aspect when judging quality especially maintainability of code.

So here are the four principles:

Contrast

In graphical design contrast is often achieved by using different font, size or color. Contrast is used to add emphasis on the really important part of a document or a work of art. But how can we add contrast to source code? For one it is done by our IDE or editor, by setting key words in a bold typeface, using a different color for text literals and so on. If you are ever forced to switch from your preferred IDE or rich editor to a simple tool like notepad you’ll see what you miss.
But even without the magic of an IDE you can and should profit from using contrast in your code. Most coding conventions go into great detail about adding contrast to code. CONSTANTS are all caps. Classes and Interfaces begin with capitals, methods, variables and fields begin with small letters.
Another way to add contrast is with comments. Who hasn’t used a comment like this?


/*********************************
DON’T DO X OR Y WILL HAPPEN
*********************************/


It’s all about contrast and most developers use it pretty reasonably in my experience.
Also if your method spans 50 lines, everything gets lost in the noise. There is just no contrast. The header of a method does add contrast.

Repetition

In graphical design this refers to repeating graphical elements to convey a feeling of cohesion. In software development repetition comes in the form of code conventions. Do your factory classes have the suffix “Factory”? Has the single instance of a singleton always the same name? While I haven’t found a group of more the one developer that could agree on a code convention without discussion, everybody always agreed on the value of code conventions. Of course Repetition should not be an excuse to use cut’n’paste! The DRY principle still applies.

Alignment

Alignment gives a clean structure to a graphical design. And it does the same for source code. Again you can apply it on various levels. It starts on the code convention level on indenting your code following simple rules. It applies on the method level as well. Do you have six nested if statements? The reader will have problems to identify the alignment and to understand your code. Or you can apply it on the package level. Has your package structure about the same depth every where? Or have 90% of your packages no subpackage at all but the remaining 10 percent have a subpackage structure 5 levels deep?

Proximity

The principle of proximity simple means: put those things together that belong together. And once more this can be applied on various levels in software development.
A package, class or method should have exactly one purpose thus putting the stuff need for this purpose inside (close together) and everything else separate. Often you have to prepare two or more objects, before putting them together. In such a case please honor the principle of proximity and put first the code for preparing the first object, then prepare the second object and so on. Don’t mix it together in some random order.
So go ahead write beautiful code.

The original idea of applying these rules to source code comes from a colleague and he told me only briefly about it on a Christmas party. But the details are from my own sick mind, so I am curious if he or any of the readers has some more ideas on applying graphical design principles to source code.