Folded files and rainbow code
In one of my first programming jobs I worked at a software house which grew its own tools. We had a home made version control system, build system, test harness and programming language. We even had our own editor!
The language was C, lightly extended to support the primitive types of our particular problem domain. The editor was more esoteric. You drove it using the numeric keypad and it modeled source code as nested blocks:
- files contained blocks of:
- includes
- documentation
- data
- functions
- functions contained groups of:
- parameters:
- in parameters
- out parameters
- initialisation blocks
- assertions
- code blocks
- loops
- machine dependent sections
- returns
The editor facilitated navigation of this nested structure, with keypresses to fold and unfold.
You don’t need to write your own editor to get the benefits of code folding: most editors support it to some degree. With this particular editor, however, folding reached its apotheosis. You could crimp and tuck and pleat, nesting layer upon layer within a single source file.
The house editor wasn’t mandated but the fold tokens it automatically placed in special comments made it challenging to work with anything else 1.
Folding made it easy to work with large files and long, complex functions. Looking back, I’d say it made it too easy — I’ve come to prefer other ways of organising code — but at the time I saw things differently. We all did. What interests me now is the effect an editor has on the shape of your code.
A wide editing pane renders long lines comfortably. Code completion makes forgettable names workable. Smart indentation keeps your code legal even as you type. Cut and paste allows you to replicate an existing function and tweak it for a new use case. Undo, redo and autosave are like version control made simple.
The folding editor failed to seduce everyone. One colleague grumbled it lacked syntax highlighting. Well, it probably came from an age before coloured pixels, and, similarly dated, at the time, I couldn’t see the need.
These days I find it hard to operate without syntax highlighting: code doesn’t even look like code if imports, literals, comments etc. aren’t visually distinct. Yet there are elite programmers who write their own programming languages using their own editors who find syntax highlighting a distraction.
Walking round the office where I work I see a diversity of editors. There are split screens and floating windows, stacked up toolbars, icons piled high. Helicopter views expose the jagged outlines of source code seen from a distance. Lenses zoom in on regions of interest. Tokens glow like plankton in deep sea colour schemes.
It’s good practice to develop code on multiple platforms even if your product targets just one. Different compilers and hardware exercise your software in different ways, making it resilient and portable. I wonder too if multiple editors scrutinize your software from different perspectives, keeping it flexible and clean.
§
My thanks to Gary Cobb for permission to use his origami dragon snap, and to willapalens for the plankton. The video clip is by Russ Cox, acme fanatic and go developer.
1: Programmers relish challenges and one seasoned emacs user had put together an emacs mode to cope with the folds.
Articles