DAVES Coding – V for Visual
By David C. Walley. Placed in the public domain 2012 Jun 20, in the hopes that you will help improve it.
A style should take advantage of the human visual cortext, to see patterns at a glance, and most importantly to see when those patterns diverge.
Looking closely should show local patterns, looking broadly should illuminate broad patterns. Good code that looks good is the goal, bad code that looks bad is detectable, but bad code that looks good is a disaster.
As a processor, the visual cortex of the human brain is remarkable. At this writing, websites are using CAPTCHAs – Completely Automated Process to Tell Computers and Humans Apart, because there are some things, such as distorted letters, which humans can recognize at a glance but are difficult or impossible for computer programs to identify.
In this contest between human and electronic brains, humans still win easily. It appears that the visual cortext is at the root of these feats of processing power.
It is possible to take advantage of this processing power in writing source code. For instance, simply by using a tabular format, where appropriate, the eye and visual cortex makes instant judgements on the existence, or breaking, of a pattern.
It is also possible to use this processing power when decorating code, such as highlighting the start of functions, or indenting. This processing power is used most critically and dangerously when judging source code at-a-glance.
There are problems with human visual processors. Optical illusions alert us to some bugs in our neural circuitry. Sometimes problems are more subtle, perhaps involving subconscious desires to see something not there.
Familiarity seems to influence what we see. If we have seen a particular pattern many times before it may give us comfort, or it may bore or infuriate us. In any case, we often make snap but lasting judgements about what we like or don’t like, trust or don’t trust. There is benefit in choosing a style that takes advantage of quick visual judgements, by aligning what we see as familiar, with good code.
Here it is in tabular form:
|Looks Good||Looks Bad|
$0.50 – about half as good as it could be
but is very, very bad.
2cents – at least we NO itsux
Some of us care more than others, but in general we strive for the upper left corner of the table, and we are happy when paid an honest dollar for writing good code. We want to create good code – that does what it is supposed to do efficiently and reliably. We also want it to look good, although what looks good to one coder may not look good to another.
From the upper right, if code looks bad, but works flawlessly, then it is best to leave it as is. Ultimately though, it is only half done, and may not be valuable as a long-term asset.
From the lower right, code that looks bad and is bad, is a minor annoyance. We should recognize it quickly, and we can move on quickly. We might even get a laugh, or learn something to avoid, so it is worth every penny of its two cents.
But in the lower left, code that looks good, but has a bug, is annoyingly expensive. Studies suggest that fixing bugs is twenty times more expensive than writing the code in the first place. Coding Standards should pay special attention to this corner – a style should make it hard for buggy code to look good.
A style should make good code look good, and bad code look bad. A style can do this, because we can change what is familiar to us through simple repetition. I have done it numerous times, when learning a new programming language or environment, and I have found it takes about two weeks to become visually comfortable.
When we see the same pattern all day, day after day, our brains adapt and become familiar with, and comfortable with, the pattern. Deviations from the pattern jump out at us, and is the source of endless debates about indentation. It is best to ignore the debates, but we should not ignore the brain’s ability to recognize familiar patterns at a glance.
Specifically, we can put this ability to valuable use if bugs are recognizable visually, if there is something uncomfortable about them that directs us to the source of a real bug.
Since we are in charge of our style, we are in charge of the visual pattern of good code, so we can design our style with the purpose of programming our visual cortex to aid in our job. I think it is a waste to squander a style\’s power on traditional gut-feeling petty debate.
It may not be possible, but it is worth trying.