[REBOL] Re: Style R flavour checker ;-)
From: joel:neely:fedex at: 10-Jan-2002 10:35
Hi, Ladislav, et al,
Ladislav Mecir wrote:
> Here are my 0,20 CZK:
>
> 1) the "density" criterium is truly objective. The trouble is,
> that it leads to unacceptable style, when used as the only
> measure.
>
I completely agree. Any style design is the result of balancing
conflicting criteria. I had assumed that the layout I was trying
out would make self-evident some of the other criteria I had in
mind, such as the use of indentation to show nesting, using degrees
of visual separation to show grouping of (sub-)expressions, etc.
about which I'm sure we agree. I was only focusing on a specific
change and assuming all else equal.
> That is why I am sure, that (objectively) a good style must (above
> all) have the property to visually separate relatively independent
> parts of the code while grouping the parts that are connected in
> some way.
>
I agree, except for the "above all" part, but I think we actually
are agreeing on the fundamental principle that the visual organization
of the source should reflect its conceptual organization. IMHO,
this single statement is what so-called "structured programming"
is all about (see footnote).
> What if the blocks are written as literals? Here is a code sample > (style 4):
>
> either some-long-logic-condition [true-block-contents] [
> false-block-contents
> ]
> either d e f
>
Here we part company. My (personal) view is that the two alternative
blocks are in some sense in a parallel or side-by-side relationship.
Therefore I prefer not to break that symmetry by positioning them
differently. I'd write the above as
either some-long-logic-condition [
true-block-contents
][
false-block-contents
]
either d e f
in Style B (and as
either some-long-logic-condition
[ true-block-contents ]
[ false-block-contents]
either d e f
in Style R) to draw attention to the facts that
a) the two blocks are side-by-side alternatives equal in importance,
b) both are under control of EITHER and its first argument.
> Other objective criteria:
>
> 1) compatibility with natives/mezzanines: MOLD, SOURCE, cut/paste.
>
> 2) compatibility with existing code base
>
The above are nice, but let's not let ourselves fall into the trap
of IBM in the 70's (or microSoft in the 90's) of becoming so
obsessive about backward-compatibility that every decision we've
ever made (for good or ill) becomes set in concrete.
> 3) zero cost of switch (not too important, I admit)
>
Agreed (on both counts).
> 4) lower cost of modification (it is easier to modify and
> expression-based style code, than a block-based style code).
>
I agree that modifiability is important. (I don't understand the
parenthetical distinction.) That's why I prefer
either some-long-logic-condition [
true-block-contents
][
false-block-contents
]
over
either some-long-logic-condition [true-block-contents] [
false-block-contents
]
precisely because extending the fully-laid-out version to read
either some-long-logic-condition [
true-block-contents
more-true-consequences
][
false-block-contents
more-false-consequences
]
requires nothing more than inserting the additional lines in either
case. Of course, if I consider the likelihood of major change to be
small enough, I'd write
either short-cond [yep][nope]
for compactness. However I'd maintain parallelism of visual layout
even if only one conseqence were long, as in
either short-cond [
yep
][
amazingly-long-block
consisting-of-stuff
for-the-nope-alternative
]
to keep the structure clearly represented.
Of course, I'm not mandating style for anybody else! Just giving
the rationale for my preferences.
-jn-
