Editors and Code Formatting

I have been using ed lately due to resurrecting a DECwriter IV for use with my PDP-11s, and it has caused me to reflect upon editing styles. I previously spent some time thinking about this when bringing up Unix V6 on said machines.

One inescapable conclusion from this experience is that tabs-versus-spaces is a thoroughly “modern” argument, brought about by the ready availability of video terminals with screen editors and automatic formatting capabilities. When you’re using ed, it is obvious that indentation is done with tabs, and only tabs, and carefully lining up columns for continuations and other clever uses of spaces are just unreasonable.

This explains K&R style. In a different sense, it also explains the almost completely uniform style of modern Lisp; Lisp editors use Emacs, and Emacs formats Lisp thus, and so Lisp is formatted thus. Of course, the end game for such an argument that tools influence code formatting is Go, with gofmt. As Rob Pike says, gofmt’s style is no one’s favorite, yet gofmt is everyone’s favorite.

Could Python have arisen in its current form in a world of ed and ex? I think probably not. For myself, I’m a four spaces guy — unless I’m using a printing terminal, or Unix Version 6.

1 Like

DEC’s pdp 8 Editor had tabs at ten spaces,just the right size to skip
past a asm label. Tabs have allways been done wrong, as real type
writers could be preset for correct spacing for documents,
I wonder, how 5 space for a tab would work for asm files, rather than
4 spaces I use for general text editing.
Ben.

Many older sources, I’ve seen, use 6 spaces for a tab stop. Incidentally, this is also what web browsers use in source view (so not that outdated at all).

Good observation. There are also storage implications as using spaces will will take considerably more disk storage than tabs. A trivial amount today and even 30 years ago so it’s hard to consider it a factor even if you’ve lived close to the time. There’s no way I would have used spaces instead of tabs in TRS-80 cassette-based editor-assembler (EDTASM) programs. With the cassette at 500 baud size mattered.

I read an interview with an Atari arcade game programmer that pointed out another angle. With their assembler setup it wasn’t possible to save the output listing to disk; it had to be sent straight to the printer. The printer being relatively slow it encouraged formatting that could print quickly. Indent as little as possible. It didn’t have bidirectional printing so short lines were better.

You might want to code like this (using tabs, of course):

loop:   sta     $10
        adc     $10
        dex
        bne     loop

But printing will be much faster if written:

loop: sta $10
adc $10
dex
bne loop

I think he said that even this was a little bit better:

loop:
sta $10
...

Never mind using loop where lp would do.

1 Like