23.10.2013 Views

FAST Forth Native-Language Embedded Computers

FAST Forth Native-Language Embedded Computers

FAST Forth Native-Language Embedded Computers

SHOW MORE
SHOW LESS

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

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!