Style R flavour checker ;-)
[1/20] from: nitsch-lists::netcologne::de at: 8-Jan-2002 13:15
Style R flavour checker ;-)
{
Hi Joel and all,
here is a littel toy to play with style R .
based on carls %clean-script.r .
clip some code, start script, see if you like it :)
-Volker
}
[ REBOL
[ Title: "REBOL Script Cleaner"
Hacked-by: "Volker Nitsch"
one-bug: "inserts empty lines sometimes"
Author: "Carl Sassenrath"
File: %clean-script-style-r.r
based-on: [%clean-script.r "rebol-library"]
Date: 30-May-2000
Email: [carl--rebol--com]
Purpose: {
Cleans REBOL scripts by parsing the REBOL code
and supplying /cut: standard/now: Style R/
indentation and spacing.
}
Note: {
Now it uses Joels Style R. and is hacked. ups.
Well, its a toy.
if Carl sees this by accident and think its more
i have to do some cleanup..
Original Note by Carl:
This script produces STANDARD script indentation and
spacing. No doubt you will want to modify it to use
your own rules. Send your enhancements and I will
consider adding them to the distribution... but keep
this header intact and keep the code clean. No hacks.
}
Category: [script util text 3]
History:
[ "Carl Sassenrath" 1.0.0 27-May-2000 "Original program."
] ]
script-cleaner: make object!
[ out: none ; output text
indent: copy "" ; holds indentation tabs
last-indent: none
tab-spaces: next detab to-string tab
big-letters: charset [#"A" - #"Z"]
emit-line: func []
[ if "" = trim/lines copy last-indent [clear last-indent]
append out newline
]
emit-space: func [pos /local more b2 bracket b1]
[ append out any
[ if newline = last out
[ any
[ if all ;move terminating bracket down
[ find "[(" bracket: first b2: back back tail out
not find "[(" first pos
]
[ clear b2 Emit-line Last-indent: tail out
join next indent [bracket tab]
]
if all
[ find ["^-)^/" "^-]^/"] back back b1: back tail out
find ")]" first pos
any ;starts line with closing bracket?
[ tail? more: next skip last-indent length? indent
find ")]" first more
] ]
[ remove b1 remove last-indent
tab-spaces
]
do
[ last-indent: tail out indent
] ] ]
if find ")]" first pos
[ if any ;starts line with closing bracket?
[ tail? more: skip last-indent 1 + length? indent
find ")]" first more
]
[ if tab = first back more [remove last-indent]
]
either find ")]" last out [tab] [""]
]
if find "[(" last out
[ either any ;starts line with opening bracket?
[ tail? more: skip last-indent length? indent
find "[(" first more
] [tab] [""]
]
" "
] ]
emit: func [from to] [emit-space from Append out copy/part from to]
clean-script: func
[ "Returns new script text with standard spacing."
script "Original Script text"
/local str new blk-rule value more
]
[ out: append clear copy script newline
parse copy script blk-rule:
[ any
[ str:
newline (emit-line) |
#";" [thru newline | to end] new: (emit str new) |
[ #"[" | #"("] (emit str 1 Append indent tab) blk-rule |
[ #"]" | #")"] (remove indent Emit str 1) |
skip
( set [value new] load/next str
either all
[ ;uppercase in line? add sme spaces
not find "^/" last out
any-word? :value find big-letters first str
not any ;starts line with opening bracket?
[ tail? more: skip last-indent length? indent
find "[(" first more
] ]
[ emit-space str
append out join tab-spaces copy/part str new
]
[ emit str new]
) :new
] ]
remove out ; remove first char
if error? error: try
[ either equal? load script load out [return out]
[ alert "formatting error (type 1)! keeping original."
return script
] ]
[ alert "formatting error (type 2)! keeping original."
return script
] ] ]
/main
make script-cleaner
[ view center-face layout [across backdrop [quit]
t1: area para [] 600x400
detab clean-script Read clipboard://
s1: slider 16x400 [scroll-para t1 s1]
] ] ]
[2/20] from: brett:codeconscious at: 8-Jan-2002 23:39
Hi Volker,
Well done. I tried it on some of my code and now I'm convinced - I need an
Un-Style R !
:-)
Brett.
[3/20] from: carl:cybercraft at: 9-Jan-2002 18:02
On 09-Jan-02, [nitsch-lists--netcologne--de] wrote:
> Style R flavour checker ;-)
> {
<<quoted lines omitted: 4>>
> -Volker
> }
Nice.
But - is style-r (which I'll always think of as Joel's style) going to
catch on amongst REBOL coders? Other people's REBOL code is hard
enough to read as it is without two styles to contend with. (:
--
Carl Read
[4/20] from: rebol:optushome:au at: 9-Jan-2002 19:35
I've been sitting back holding off commenting, but can't hold off forever.
If you really want to make it easier for maintenance programmers, all I can
say is to repeat the Designer's Tip Sheet.
Tip #7 Code in Style
REBOL is a highly dynamic language that allows massive creative freedon in
script's design. But, when it comes to the source format of your script, use
the standard style (found in the REBOL User's Guide). Adhering to a standard
style will make your script easier for you and others to read
I see little point in using a style different to the style that is in used
REBOL itself. For one thing the source function loses some of its utilty if
you have to mentaly map from the standard formatting to your own style.
If you have trouble reading the standard style, then maybe you haven't
truly learnt to read REBOL yet.
(or you might be carrying too much baggage from past languages.)
Please stick to the standard guide as much as you can, at the very least
please stick to it for posts to this list.
When in Rome... etc
Cheers,
Allen K
[close vent]
[5/20] from: carl:cybercraft at: 9-Jan-2002 23:58
On 09-Jan-02, Allen Kamp wrote:
> I've been sitting back holding off commenting, but can't hold off
> forever. If you really want to make it easier for maintenance
<<quoted lines omitted: 9>>
> of its utilty if you have to mentaly map from the standard
> formatting to your own style.
But RT could change the output with the next release of REBOL.
> If you have trouble reading the
> standard style, then maybe you haven't truly learnt to read REBOL
> yet. (or you might be carrying too much baggage from past
> languages.)
Nah - it's to get away from the look of other languages and to have a
more REBOL-like style - to emphasize the blocks as much as possible.
Plus, it's just plain better.
> Please stick to the standard guide as much as you can, at the very
> least please stick to it for posts to this list. When in Rome... etc
Vote?
> Cheers,
> Allen K
> [close vent]
(:
--
Carl Read
[6/20] from: petr:krenzelok:trz:cz at: 9-Jan-2002 12:10
Carl Read wrote:
> > If you have trouble reading the
> > standard style, then maybe you haven't truly learnt to read REBOL
<<quoted lines omitted: 6>>
> > least please stick to it for posts to this list. When in Rome... etc
> Vote?
Maybe I will be just intollerant, but RT's style is the only one I will
use. I am used to it already and none of ABCDEFGH styles presented showed
any evident advantage for me to change my mind :-)
So, I back up Allen's opinion :-)
-pekr-
[7/20] from: brett:codeconscious at: 9-Jan-2002 22:34
Hi Carl,
> Vote?
Sorry but I don't think a vote will be helpful.
My position is in basic agreement with Allen.
I'll add that I haven't seen an overwhelmingly better style than the
standard yet. So I don't think there is any point making changes that will
result in inevitable confusion. I also believe that people who may have
just joined the list will already be experiencing some difficulty with
recent posts that use a different style.
The value of coding style (as laid out by the vendor) in the Powerbuilder
world is so strongly recognised that you don't pass a job interview unless
you know it.
I think RT will, and needs to, lead the way and I'm quite confident that if
a much better style is developed it will be adopted. But it would have to be
brilliant. :)
I think there could also be some effort put towards ways of dressing up the
existing standard style (via for example spacing/comments) that will make it
more visually pleasant.
Brett.
[8/20] from: rebol665:ifrance at: 9-Jan-2002 13:49
Hi, all
I'am afraid that this is becoming a sensitive matter. I would not like to
see a war starting between the rebol-listers. I cannot recall who started
this, but it was an interesting thread. However I agree with Allen point of
view.
> I see little point in using a style different to the style that is in used
> REBOL itself.
Patrick ( a voté )
ps : my main problem is the code ending with ] ] ] (as in the following code
from Joel Neely's RF article). These are not natural for me (sorry joel).
nbt: func [b [block!] /local rt cur pen front ]
[ rt: 0 cur: b pen: []
forever
[ either empty? cur
[ either empty? pen
[ return rt]
[ cur: first pen pen: second pen]
][ either block? front: first cur
[ pen: reduce [next cur pen] cur: front]
[ rt: rt + front cur: next cur]
] ] ]
[9/20] from: chris:starforge:demon at: 9-Jan-2002 13:18
pat665 wrote:
> Hi, all
>
> I'am afraid that this is becoming a sensitive matter. I would not like to
> see a war starting between the rebol-listers.
But.. but.. Holy Wars are fun! Or something...
> ps : my main problem is the code ending with ] ] ] (as in the following code
> from Joel Neely's RF article). These are not natural for me (sorry joel).
I can't really comment as my style changes slightly depending upon my mood
(this is true regardless of the language I am using) but I too find the
] ] ] scheme rather disconcerting, if only because C and its ilk have
trained me over the years to do
]
]
]
when matching brakets across multiple lines. Call it psychological damage
if you will :)
Chris
--
.------{ http://www.starforge.co.uk }-----. .--------------------------.
=[ Explorer2260, Designer and Coder \=\ P: TexMaker, ROACH, site \
=[___You_will_obey_your_corporate_masters___]==[ Stack: EETmTmTRRSS------ ]
[10/20] from: mat:b:codeplay at: 9-Jan-2002 12:08
Hello,
I'm trying to get Rebol to work with Xitami. I've actually done it
before but the box suffered a melt-down. I'm not really interested in
doing anything fancy like that fast-CGI type implementation. I just
want to do some very simple stuff such as you see in the script
library.
Anyone know exactly what you do? I've tried a load of different
things.
Regards,
Mat Bettinson
Codeplay
Tel: +44 (0)20 7482 3382
140-142 Kentish Town Rd, London, NW1 9QB
http://www.codeplay.com
[11/20] from: jason:cunliffe:verizon at: 9-Jan-2002 11:35
I agree with Allen's comments about the virtues of publicly consistent
style.
As REBOL succeeds more, and the sizxe of its contributed library and
user-populatino grows, this becomes a much more important issue.
That has been one of the major success stories of Python. Python uses white
space indentation, thus to write syntactically correct code, all Pythoneers
must write in consisstent readable style. This was a major design feture,
and makes it excellent for both novice and advanced user.
It seems to me that REBOL needs better tools and strategies only. Ideally a
really cool editor written in REBOL for REBOL. "REBEDIT" could also become a
great showpiece, allow people to learn from it, enhance it, customize it,
benefit from built-in FTP, http etc.. and be 100% cross multi-platform.
Most of the pieces exist already.. With such an editor, those who prefer
individual 'house' styles would be free to select [A-Z]. The editor would
then parse incoming code adn pply selected style. When saved or sent
[uploads/transfers], it would re-convert tranparently to the [global] REBOL
standard style. In other words expand on an idea REBOL already implements
when open and saving code which has travelled across platforms to fix line
endings transparently.
Is REBOL fast enough to this & compete with exiting editors?
How big a project is this?
Request for Features?
..
The code folding [collapse/expand] suggestion is a very good one.
Python has this also in the editor/shell whihc comes with PythonWin. This is
based upon Scintilla [A free source code editing component for Win32 and
GTK+]
http://www.scintilla.org/
Mathematica developed the original idea I think with its wonderful notebook
interface. I use UltraEdit irght now as my default text editor, this
includes a crude hide/show tool, nice color syntax highlighting, smart
indentation and built-in FTP. Most of what is needed, but I would jump for
REBEDIT. How about you?
./Jason
[12/20] from: sunandadh:aol at: 9-Jan-2002 13:03
Hi all,
Allen Kamp:
> I see little point in using a style different to the style that is in used
> REBOL itself.
But I do!
I have two problems. One minor and one more important.
Minor point: many bits of Rebol are good examples, but there some bad
examples in there too. Asking someone to "do what Rebol does" is not enough.
I don't like one-letter variables (source Request) or variables which are
just misspelt words (source Request-list). That's just sloppy and I don't
want to copy that style
But I think you meant your remark to refer mainbly to source layout, not
variable names.
So, more importantly: Rebol's style and my way of visualising block just
don't click. Psychologists will tell us that people think in different ways.
The code I produce is a result of the way I visualise and think. And there is
not a natural match between Rebol's published style and my development style.
If I had to write that way I'd walk away from the language. Simple as that.
And I doubt if I'd be the only one.
But I have no trouble at all with there being a single "house style". My code
can be reformatted however a prettyprinter likes for publication. Just as
when I write for magazines they pour my text into their house style at the
last moment, saving me from writing in narrow columns and leaving space for
adverts.
And if the prettyprinter had enough options that I could turn other people's
code into something close to what I prefer and can work with, well that's a
win/win/play-again situation for all of us.
(Wow! I got through that without mentioning the Style Police. and thus almost
falling foul of Godwin's Law)
Sunanda.
[13/20] from: joel:neely:fedex at: 9-Jan-2002 16:09
Hi, Pat, and all,
pat665 wrote:
> Hi, all
>
> I'am afraid that this is becoming a sensitive matter. I would
> not like to see a war starting between the rebol-listers.
>
I agree (with both statements).
> I cannot recall who started this...
>
Blame me, but first reread my original post:
This is a controversial and sensitive subject with some
folks. I'm not trying to start a flame war, and I have
no interest in debating aesthetic opinions. I *am* very
interested in objective criteria which identify strengths
and weaknesses of the alternatives.
I was planning on waiting a while before trying to summarize my
observations of the discussion, but I agree with Pat's perception
that the temperature is rising a bit fast.
Dijkstra has often used the phrase "separation of concerns" in
discussions on software development. He distinguishes what he
calls the "mathematical" concerns -- whether a program behaves
correctly/accurately -- from "engineering" concerns -- whether
the program exhibits appropriate economies in its behavior.
While a good programmer is concerned with both, it is appropriate
to know at any moment *which* of these issues one may be most
directly engaging, and to be able to discuss them separately.
(I believe it was Don Knuth who observed that, in programming,
premature optimization is the root of all evil
.)
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
of nesting.
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
topics).
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.
I think it is ironic that the "layout style" thread occurred
concurrently with another instance of a topic that re-appears
every few months on this mailing list: the issue of promoting
REBOL in our various environments. I suggest that there are
some instructive parallels.
A suggestion that we look at an alternative layout style was met
with a variety of reactions:
- "Interesting!"
- "I like it!"
- "I don't like it!"
- "I don't see the point."
- "What we've always done is good enough."
- "Here's an apparent limitation.", followed by
"Here's a way to deal with that."
- "Why are you rocking the boat?"
A suggestion that a development team already using Java, Python,
Perl, c++, (or whatever...) consider another programming language
(REBOL) is often met with responses that boil down to the same
reactions as those above.
Perhaps a look within ourselves, and at our reactions to the idea
of change will give us some insight into how others respond when
ask them to take a look at REBOL (another kind of change).
My thanks to everyone who has contributed to the discussion. Again,
let me say that my motivation wasn't to "own" a new style, nor to
rock the boat unnecessarily, but to discuss whether a style that
evolved within the Algol heritage was the best approach for a very
non-Algol-like language.
-jn-
P.S.: I'll gladly comply with the judgement of the editor-in-chief
as to whether the refactoring article should be resubmitted with the
examples in a more conventional style.
[14/20] from: richard-boyd:worldnet:att at: 9-Jan-2002 21:51
-Sunanda >> I strongly agree with your summary.
-Volker >> When I first tried your "cleaner" on some of my script, I thought your clean-script-style-r
was not working because I didn't notice much difference when I toggled between my original
code and the "cleaned" version output from your script. Then I realized why ... there
wasn't much difference!! I am going to try modifying my style from "L" to "R" ... just
because of the convenience of being able to use your pretty printer on it ... as per
my Smalltalk days. Thanx for a nice tool.
-richard-
[SunandaDH--aol--com] wrote:
[15/20] from: sunandadh:aol at: 10-Jan-2002 6:04
Hi Joel,
> I was planning on waiting a while before trying to summarize my
> observations of the discussion, but I agree with Pat's perception
> that the temperature is rising a bit fast.
Thanks for your summary, and the call to cool it. I think is was the current
US President Bush who pointed out the someone you agree with 80% is not your
enemy. And I'm sure we all agree far more that that on the value of Rebol.
I guess I got slightly sharp because though I'm happy to listen to (and
contribute) passionate opinions and persuasive options, I react badly to what
I read as policy orders.
I must learn to chill out before I chip in.
Sunanda
[16/20] from: rebol665:ifrance at: 10-Jan-2002 12:57
Hi,
If it is time to invoke J.W.Bush wisdom (some call it bushism), we are far
beyond the point I had feared. I still hope the Jihad is not started? (see
for details http://www.unn.ac.uk/societies/islamic/jargon/jihad1.htm ).
Patrick in 80% agreement with Sunanda
[17/20] from: joel:neely:fedex at: 10-Jan-2002 0:16
Hi, Sunanda, et al
[SunandaDH--aol--com] wrote:
> Hi Joel,
>
> > I was planning on waiting a while before trying to summarize my
> > observations of the discussion, but I agree with Pat's
> > perception that the temperature is rising a bit fast.
>
> Thanks for your summary, and the call to cool it.
Let me emphasize that my comments weren't about, nor directed to,
anyone in particular. I found the range of reactions quite
fascinating!
As someone who routinely writes and reads several different
programming languages, I tend to "look through" layout style to
the meaning of the code, and therefore think of layout as being
something one simply decides on (and may try changing), just as
I decide which shirt to wear. I forgot that some cultures have
dress codes and react very emphatically when the code is not
taken seriously! ;-)
I should also add that, while I have no concerns over different
people using different styles, I accept Allen's point that there
is societal value (especially for recent "immigrants" to the
language) in having some consistency in "officially" published
code, especially when it is offered as "how to" examples. I'll
be submitting a revised version of the refactoring article to
REBOLforces which uses the conventional layout style in all of
its examples. (It makes the source text and printed web pages
both about 10% longer...)
Of course, I regard code posted for the purpose of discussing
coding styles to be an exception to the general principle of
the last paragraph... ;-)
-jn-
--
Seen in a foreign hotel: Visitors are expected to complain at the
office between 9 and 11 am daily.
-- [krm--mail--ips--ca]
joel0dot0neely0FIX0PUNCTUATION0at0fedex0dot0com
[18/20] from: lmecir:mbox:vol:cz at: 10-Jan-2002 14:31
Hi all,
<<Joel>>
(...)
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
of nesting.
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
topics).
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.
(...)
<</Joel>>
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
density" style.
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
indeed-very-long-false-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] [
false-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
line.
For me, Rebol is expression-based, not block-based, that is why I prefer an
expression-based style.
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).
Cheers
Ladislav
[19/20] 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-
[20/20] from: carl:cybercraft at: 11-Jan-2002 11:47
On 10-Jan-02, Joel Neely wrote:
> I should also add that, while I have no concerns over different
> people using different styles, I accept Allen's point that there
> is societal value (especially for recent "immigrants" to the
> language) in having some consistency in "officially" published
> code, especially when it is offered as "how to" examples.
This was why I thought some agreement on whether style-r was a good
thing should be sought. Not that I'd be adverse to allowing nature
to take its course and just letting the most popular style win
through. (:
> I'll
> be submitting a revised version of the refactoring article to
> REBOLforces which uses the conventional layout style in all of
> its examples.
But how about also keeping a copy of the style-r version on the site
too as an example of an experiment of a different REBOL style? Could
be useful for those thinking of writing dialects - it's a good
example of the different ways of thinking about scripting styles.
> (It makes the source text and printed web pages
> both about 10% longer...)
The few experiments I did seemed to indicate you'd save about 1 line
in ten. I wonder how much shorter it would've made the Core User
Guide? Save enough pages to give it an index with no extra cost
perhaps? (;
--
Carl Read
Notes
- Quoted lines have been omitted from some messages.
View the message alone to see the lines that have been omitted