Re^6: How has your coding style changed over the years?

In my perception/style, that end (and done) should be indented

sh:

for i in 1 2 42 ; do
    echo $i
    done

csh/tcsh:

foreach i (1 2 42)
    echo $i
    end
[download]

It is all about the visual understanding of the code-flow. You read the statements start (if/while/do/for/unless/…) en see the *block* will not be executed, and you need to navigate to the next statement (which of course has the same indent), The end is not the next statement, but the (visually uninteresting) end/close of the block belonging to the statement you just skipped. My brain doesn't want to see that end at all when browing code.

In your Ruby example do and end are syntax only. The represent no action whatsoever and act as { and }. All of them are no statements: they are syntax (to mark start and end of a block), just like ; is to mark the end of a statement.

Enjoy, Have FUN! H.Merijn

Comment on Re^6: How has your coding style changed over the years? Select or Download Code

Replies are listed 'Best First'.
Re^7: How has your coding style changed over the years? by LanX (Saint) on Aug 11, 2022 at 13:53 UTC
I understand your motivation and I can see the advantages if the eye can easily "fall thru" to the next statement on same syntax level. But I doubt that the "end" was always meant to be part of the block. My guess is it evolved from a jump label in assembler, as such a reentry point into the higher level. Cheers Rolf _{(addicted to the Perl Programming Language :) Wikisyntax for the Monastery}	[reply]
Re^7: How has your coding style changed over the years? by Fletch (Bishop) on Aug 11, 2022 at 14:01 UTC
(Caveat this is of course a subjective almost aesthetic argument and maybe no one's really wrong (except this is just horrible . . . 0.25:) ) It feels as if you've (almost) reimplemented python's terrible indentation-is-block structure but kept the requirement that you have to have a non-whitespace terminator token present. With this scheme it seems the worst of both worlds in that you both have to watch indentation levels like a hawk (maybe not a hawk because it's not whitespace semantically significant; perhaps like a slightly drunk kestrel or some other minorly impaired raptor . . .) but also still need to parse out and read for the terminator that also has to be there. If there's going to be an explicit terminator then it should be visually interesting (i.e.* exdented) so it can be picked out of the flow of the meat of the block. With this scheme I'd feel one can't skim over the contents of the block as easily because the end terminator of said block doesn't stand out so one is then stuck actually parsing the entire block text to find it / make sure the block is syntactically valid. But again, personal aesthetics tomayto tomahto let's call the whole thing off. And a very tangentially related aside: for command line usage I like the `short_loops` option for zsh which lets you elide the `do/done` and use a braced list instead: `for i in a b c d ; { print $i ; $i/bin/do_foo }` The cake is a lie. The cake is a lie. The cake is a lie.	[reply] [d/l] [select]
Re^8: How has your coding style changed over the years? by GrandFather (Saint) on Aug 12, 2022 at 03:53 UTC
For almost all of us "indent is block" is standard. The difference with Python is indent structure is forced by the language and breaking lines in sensible places becomes a real PITA. Optimising for fewest key strokes only makes sense transmitting to Pluto or beyond	[reply]