[REBOL] Re: Style R flavour checker ;-)
From: lmecir:mbox:vol:cz at: 10-Jan-2002 14:31
Since programming languages induce subcultures, it seems to me
that any discussion of stylistic issues involving a specific
language engages three separate areas of concern:
1) Objective -- things that can be measured (even if statistically,
in a human factors sense) in a non-ambiguous manner; e.g.
how many lines are required for a given piece of source code,
depending on formatting style.
2) Personal -- things that are a matter of individual preference,
aesthetics, taste, etc.; e.g. my previously-mentioned personal
dislike for all-upper-case text.
3) Cultural -- things that are a matter of tradition, convention,
custom, etc., within a specific society; e.g. the practice
within the REBOL community of indenting by 4 spaces per level
I began experimenting with layout to see whether there was a way
to increase the amount of content within a given area of real
estate, whether editor screen, browser window, or printed page.
I was focused on #1 above.
I'm very aware that factors #2 and #3 are entangled in anything
with as much personal choice and feeling as how one writes code,
but I see some value in applying separation of concerns to the
discussion of this issue (as well as many other programming
I'll leave it to each individual to read this thread and think
about how much of #1, #2, and #3 are present in the various parts
of the discussion.
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.
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. Let's start with a
simple code (style 1):
either a b c either d e f
The style 1 code sample is written on one line omitting the fact, that it
contains two, relatively independent expressions (style 2):
either a b c
either d e f
Style 2 underlines the fact, that the code can be separated to two
expressions. That is why I prefer style 2 here, although it is a "low
Now let's consider a situation, when the CONDITION, TRUE-BLOCK and
FALSE-BLOCK arguments of the EITHER function are much longer (style 3):
either indeed-very-long-logic-condition indeed-very-long-true-block
I would prefer the expression to be on one line, because it is just one long
expression, but I am out of luck here. I expressed the fact, that it is just
one expression, using indentation of the second line, which is
understandable for humans as far as I know.
What if the blocks are written as literals? Here is a code sample (style 4):
either some-long-logic-condition [true-block-contents] [
either d e f
Style 4 looks even better, than style 3, because it not only shows the fact,
that the first EITHER expression is one expression (that doesn't fit on one
line, though), but it visually separates it from the next expression using
the "]", while the fact, that the expression doesn't end at the first line
is expressed by indentation as well as by the "[" at the end of the first
For me, Rebol is expression-based, not block-based, that is why I prefer an
Other objective criteria:
1) compatibility with natives/mezzanines: MOLD, SOURCE, cut/paste.
2) compatibility with existing code base
3) zero cost of switch (not too important, I admit)
4) lower cost of modification (it is easier to modify and expression-based
style code, than a block-based style code).