Code Layout Matters

From WikiContent

(Difference between revisions)
Jump to: navigation, search
m
Line 1: Line 1:
-
An infeasible number of years ago I worked on a Cobol system where staff weren't allowed to change the indentation unless they already had a functional reason to change the code. Presumably, this was because someone once broke something by letting a line slip into the special columns at the beginning of the line. Unfortunately, this applied even if the layout was misleading, which it sometimes was, so we had to tread very carefully when reading the code because we couldn't trust it. The policy must have cost a fortune in programmer drag. This is a nice example of why code layout matters.
+
An infeasible number of years ago I worked on a Cobol system where staff weren't allowed to change the indentation unless they already had a functional reason to change the code. Presumably, this was because someone once broke something by letting a line slip into the special columns at the beginning of the line. Unfortunately, this applied even if the layout was misleading, which it sometimes was, so we had to read the code very carefully because we couldn't trust it. The policy must have cost a fortune in programmer drag and is a nice example of why code layout matters.
 +
 
 +
There's research to show the we all spend much more of our programming time navigating and reading code—finding ''where'' to make the change—than actually typing, so that's what we want to optimise for.
 +
 
 +
I want to make scanning code as easy as possible. People are really good at visual pattern matching (probably a leftover from the time when we had to spot lions on the Savannah), so I can help myself by making everything that isn't directly relevant to the domain, all the “accidental complexity” that comes with the languages most of us get to use, fade into the background by standardising it. If code that is structurally the same looks the same, then my perceptual system will help me pick out the differences.
 +
 
 +
I want my code layout to be as expressive as its content. We've all learned nowadays to take the time to find the right names so that our code expresses as clearly as possible what it does, rather than listing the steps. Sure we have. The code's layout is part of this expressiveness too.
 +
 
 +
I want a compact format so that
 +
 
-
I spend much more of my programming time navigating and reading code than typing. The hard part is usually finding ''where'' to make the change, so I want to make scanning code as easy as possible. One optimisation is to try to make everything that isn't directly relevant to the domain, all the ''accidental complexity'' that comes with our workaday languages, fade into the background by standardising it. People are really good at visual pattern matching, it's a leftover from the time when we had to run away from lions, so
 

Revision as of 15:13, 25 November 2008

An infeasible number of years ago I worked on a Cobol system where staff weren't allowed to change the indentation unless they already had a functional reason to change the code. Presumably, this was because someone once broke something by letting a line slip into the special columns at the beginning of the line. Unfortunately, this applied even if the layout was misleading, which it sometimes was, so we had to read the code very carefully because we couldn't trust it. The policy must have cost a fortune in programmer drag and is a nice example of why code layout matters.

There's research to show the we all spend much more of our programming time navigating and reading code—finding where to make the change—than actually typing, so that's what we want to optimise for.

I want to make scanning code as easy as possible. People are really good at visual pattern matching (probably a leftover from the time when we had to spot lions on the Savannah), so I can help myself by making everything that isn't directly relevant to the domain, all the “accidental complexity” that comes with the languages most of us get to use, fade into the background by standardising it. If code that is structurally the same looks the same, then my perceptual system will help me pick out the differences.

I want my code layout to be as expressive as its content. We've all learned nowadays to take the time to find the right names so that our code expresses as clearly as possible what it does, rather than listing the steps. Sure we have. The code's layout is part of this expressiveness too.

I want a compact format so that



Working clean.

By Steve Freeman

This work is licensed under a Creative Commons Attribution 3


Back to 97 Things Every Programmer Should Know home page

Personal tools