FAST Forth Native-Language Embedded Computers
FAST Forth Native-Language Embedded Computers
FAST Forth Native-Language Embedded Computers
Create successful ePaper yourself
Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.
Garth Wilson<br />
Whittier, California<br />
I had been thinking about writing an article on read-<br />
ability of <strong>Forth</strong> code, but I became more determined after<br />
going through a recent issue of <strong>Forth</strong> Dimensions. It was<br />
full of things that reduce code readability, cover to cover.<br />
It's no wonder some have called <strong>Forth</strong> a write-only<br />
language! It doesn't need to be this way. If a programmer<br />
gets the application working but the code is unreadable,<br />
he hasn't done his job.<br />
After looking through my library at others' treatments<br />
of the subject, a part I see as lacking special attention is<br />
what Jack Ganssle calls "pretty code."' It has not been<br />
stressed enough in our programming industry. I've had<br />
non-programming superiors who thought that any work<br />
beyond "just getting it working" was frivolous, and that the<br />
programmer who spent the time was not sensitive to the<br />
company's needs.<br />
Jack Ganssle tells of a Volkswagen Beetle maintenance<br />
book he had which strongly encouraged the owner to<br />
keep the engine clean. One reason was that you're more<br />
likely to keep it in good shape if you can do the necessary<br />
Producing readable code<br />
is not an objective procedure<br />
with an exact formula.<br />
maintenance without getting filthy. We've all seen a lot of<br />
"filthy engines" in our industry-ones we don't want to<br />
touch.<br />
I've had code that was sold as "toolbox" code that was<br />
too unreadable to figure out what was necessary in order<br />
to use a small piece of it in my own application. I thought,<br />
"Why'd they even bother?" It doesn't have to be that way.<br />
Special attention will be given here to layout, and to<br />
making the layout more perceptible. "Layout" here refers<br />
to the decisions as to whatwords will be put on a particular<br />
line of source code, where in the line they will start, use<br />
of blank lines to separate code "paragraphs," where the<br />
comments will go, etc. Let's look first at vertical alignment,<br />
then line breaks, zero-stack-effect lines, comments (in-<br />
cluding stack-effect), and case.<br />
* "The C Blues," <strong>Embedded</strong> Systems Programming, April 1993<br />
March 1994 April<br />
Vertical Alignment<br />
Comprehension is accelerated dramatically by vertical<br />
alignment of related elements. Structure words need to be<br />
aligned vertically unless the structure is very simple; for<br />
example, BEGIN ?TERMINAL UNTIL would fit nicely on<br />
a single, very readable line; but ?DO and LOOP in Listing<br />
One need to be one above the other, obviously standing<br />
out from the contents of the loop.<br />
The indentation should be at least three spaces. Re-<br />
cently I was trying to read some code in a book. The<br />
indentation for setting off loops was only one space,<br />
which made it look like the printhead just didn't come<br />
back to the same place with every carriage return, produc-<br />
ing a ragged margin.<br />
Having many nested structures can be a pain, and can<br />
usually be avoided by making each nested level a separate<br />
definition. In some cases, however, it is difficult to come up<br />
with a truly descriptive colon-definition name that's any<br />
shorter than the code itself. Having neither good names nor<br />
the code right there, you will have trouble understanding<br />
the flow of what the code is supposed to do. Vertical<br />
alignment and readability can still be preserved using<br />
methods like the one shown in Listing Two-a instead of<br />
Listing Two-b.<br />
Listing Two-b is far more confusing, and takes just as<br />
many lines, despite the lack of blank lines to set off the<br />
different parts. I've seen this kind of thing carried to the<br />
extreme, making a huge sideways 'V' from the top of the<br />
printed page to the bottom, with the point of the 'V'<br />
indented so far over to the right that it left no room for<br />
comments.<br />
Many <strong>Forth</strong> programmers would say a definition should<br />
never get this long, and would proceed to "flesh it out" in<br />
<strong>Forth</strong> one-liners, requiring many, many levels of nesting<br />
at execution time. I would go along with this only as long<br />
as the colon-definition names are very descriptive of what<br />
they do, and that the "fleshing out" is not used as a<br />
substitute for good commenting or layout.<br />
Vertical alignment of similar words on lines helps, too.<br />
Our brain homes in on patterns that simplify the mental<br />
processing and memory requirements of the material.<br />
Consider Listing Three-a. These simple definitions can be<br />
I <strong>Forth</strong> Dirnensior