Re: DCL Coding Standards
From: David J. Dachtera (djesys.nospam_at_NeOaSrPtAhMlNiOnWk.net)
Date: 04/04/04
- Next message: Fabio Cardoso: "Re: OT: fingerprint processing"
- Previous message: Barry Treahy, Jr.: "Re: :-) BOFH needs VMS"
- In reply to: Alan E. Feldman: "Re: DCL Coding Standards"
- Next in thread: Alan E. Feldman: "Re: DCL Coding Standards"
- Reply: Alan E. Feldman: "Re: DCL Coding Standards"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Sun, 04 Apr 2004 11:59:39 -0500
"Alan E. Feldman" wrote:
>
> "David J. Dachtera" <djesys.nospam@NeOaSrPtAhMlNiOnWk.net> wrote in message news:<406E3E9C.63D50EFE@NeOaSrPtAhMlNiOnWk.net>...
> > [snip]
> > Probably because you also "over-indent". Compare:
>
> No, I also like the underscore when the label appears in a command. I
> tried that once for variables but found it too tedious.
>
> > $_label:
> > $ IF (BLAH.EQS.BLEH)
> > $ THEN
> > $ exciting loop command
> > $ exciting loop command
> > $ exciting loop command
> > $ ENDIF
> >
> > ...to...
> >
> > $label:
> > $ IF (BLAH.EQS.BLEH)
> > $ THEN
> > $ exciting loop command
> > $ exciting loop command
> > $ exciting loop command
> > $ ENDIF
> >
> > Nearly identical visual effect, fewer bytes (TABs instead of spaces) and
> > things line up at TAB stops making editing much less keyboard-intensive.
>
> As read on Google, there was no indenting in your example.
Be careful about comparing an HTML rendition to a "normal" character
cell display. View the page source or "original format" for a more
accurate representation.
> In this
> window in which I am responding, there is indenting. Just shows that
> you suffer from TAB-character disease and we can see here some of its
> ill effects.
If the tab stops are off, reset them to the default of every 8 columns.
Some ill-behaved programs - or displaying binary stuff to the screen -
tend to goof up the display.
> Apparently Google doesn't like TAB characters and removes
> them,
Well, no - remember how HTML works. Unless text is enclosed within <pre>
and </pre>, the rendition will range from inaccurate to unpredictable.
> except in this reponse window! Whatever. ... OK, I checked it in
> the preview window and the tabs are still there. But they are not when
> I click "Read the rest of this message" to see all of your post.
Say, "HTML".
> I
> think TAB's would be better if they inserted the appropriate number of
> spaces for each use than an actual tab character, at least for text
> like this.
Say, "MS-DOS Editor".
> And I wonder if the tabs will somehow reappear when I post
> this. Only a few hours of time will tell!
>
> My way makes it easier to find labels.
...as long as "$_" is consistent, yes: FIND for "$_" will locate labels.
Then again, given:
$ GOTO label_1
.
.
.
$ GOTO other_label_1
..., FIND for "$label_1:" will distinguish it from the other form, as
long as "$label_name:" is used consitently. Matter of preference...
> I like the whitespace between
> the commands and the $'s.
Lotta folks do, it seems. Not sure why - bloody pain in the ass to have
to waste time counting spaces like that...
> As for keyboard intensive; for me, anyway;
> the problem is going for the "computer-only" keys.
I've yet to see a computer keyboard - from a teletype to a 3270 - that
didn't have a TAB key, or a typewriter either for that matter.
> A few hits
Per line??!!
> on the
> space bar are no big deal for me. In fact it gives my thumbs a break
> from hovering, which I find more straining. It's the "difficult
> typing" I seek to avoid. And the labels are too "cramped" your way.
Depends.
> Well, to each his own. Diff'rent strokes,.... Readability is in the
> eyes
(lenses, cornea, retina, ...)
> of the reader.
>
> > > And unnecessary parentheses make
> > > IF THEN statements more readable.
> >
> > Well, yes and no. Which paren.'s in the following would you consider
> > "unnecessary"?
> >
> > $ IF ((BLAH .AND. %X7FFFFFFF) .EQ. BLEH)
> >
> > $ IF (BLAH .AND. %X7FFFFFFF) .EQ. BLEH
> >
> > Hint: Putting spaces around your operators increases readability more
> > than "unnecessary" paren.'s.
>
> Well, they're all unnecessary here,
Are they? Check DCL's order of precedence for operators. You may find
yourself coding one thing and getting another if you don't
"parenthesize" properly. "Outer" paren.'s tend to be superfluous, while
"inner" paren.'s are more sensitive.
> but I like the first one better.
> I'd like it even more if there were no spaces around the .AND. and
> .EQ. operators. It's eaiser on my eye that way.
How so? Seems harder to distinguish between symbols and operators,
especially after working in other languages where dots are valid in
variable names and/or other language elements.
> More information and
> less scanning. I guess my eyes don't like horizontal scanning as much
> as yours do. And you can get more on a line without extra spaces. The
> periods provide enough "whitespace" for me. In the second version the
> BLEH looks like it's kind of on its own -- not really part of the main
> command. Just my view of it, mind you.
Also, other language processors may require spaces or TABs to delimit
statement elements. I'm pretty sure
$ IF XORY
would not be valid BASIC syntax, unless the symbol "XORY" were actually
valid and expected to be treated as a truth value.
It's easier for me to remember how operator names differ between
languages and observe standard rules for element delimiters (spaces,
TABs, etc). than to change delimiters depending upon the language.
> I also like the first one better because the outer parens clearly show
> that their contents comprise a single entity on the command line.
>
> OTOH, I might write it like the following:
>
> $ IF ( (BLAH.AND.%X7FFFFFFF) .EQ. BLEH )
>
> Just personal preference; I wouldn't have an apostrophe over it.
Apostrophe? Don't see one in any of the examples. What did I miss?
> Beware apostrophe disease! Its catching it's own self! '-)
Actually I use "&" where I can...
-- David J. Dachtera dba DJE Systems http://www.djesys.com/ Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/
- Next message: Fabio Cardoso: "Re: OT: fingerprint processing"
- Previous message: Barry Treahy, Jr.: "Re: :-) BOFH needs VMS"
- In reply to: Alan E. Feldman: "Re: DCL Coding Standards"
- Next in thread: Alan E. Feldman: "Re: DCL Coding Standards"
- Reply: Alan E. Feldman: "Re: DCL Coding Standards"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
