RE: Free-form RPG standards

>but, as you pointed out, it's a holy
>war that will never get resolved.

Well, maybe.  It's been my experience that code is copied from one program
to start another.  I can't tell you how many times I've seen arrays used for
printer headings in O spec code, because some old class had it that way.
"Joe" learnt it that way and every one of his programs looks the same to
this day.

If you have a preference for how your code should look, I strongly suggest
that you get coding and make your code the example that others will follow.
I don't have any strong recommendations myself; _which_ style I use is far
less important than using _a_ style.  When I go into somebody else's code, I
don't impose my coding style on it; I mimic the style that's already there.
It's much easier to read and therefore debug in the future if the code looks
cohesive.

There are many, many examples of free-form coding style.  Pick a language
that you're familiar with and scan the style guides on the net.  Or, get
some ideas from McConnell's Code Complete.

For me, the key is that the formatting should clarify the code, not dominate
it.  Imagine doing maintenance on the code; moving a block around.  Now it's
in a different "indent level."  How much work will it be to re-format?  Will
the guy who moved it be tempted to leave a "false" indent level?  Will I
have to adjust the position of my parameters on a call?  Tinker with a block
of code like this; move it into deeper and shallower indent levels; how hard
is it to retain reasonable formatting?

eval newSONum = getNewSONum
if newSONUM = -1        //error
  exsr badSoNum
else                    // error - else
  exfmt getHdr
  callp writeSoHdr(newSoNum:
                   custNo:
                   shipToName)
endif                   // error

  --buck