That’s really interesting and I don’t think I’ve encountered it. Initially I wanted to dislike it because I see balanced characters as needing whitespace balance. So that style would be roughly equivalent to something like for (@array ) { …, which rankles. But the vertical space with the closing brace makes it “work” and the block indentation argument is logical. Hmmm… you might have made a convert.

> In other words: I see the braces being part of the block,

I don't understand this argument. From all languages I remember using an end keyword, I can't remember any seeing it as part of the block, but indenting it as part of the surrounding construct.

e.g. Ruby

 
block_name do 

   #statement-1  
   #statement-2  
   .
   .
end
[download]

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

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}

(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.

I'm curious to know why the opening brace goes on the conditional line.

It is reassuring that someone else uses the same argument for indented braces that I do. It seems to be a highly unusual thing!

The opening brace goes on the line of the statement because

• It saves vertical space: now I can see more code on my screen/window and have a bigger (over)view on the context
• As the closing vrace, it is just syntax and by that reason does not deserve a line of its own
• The closing brace has a line of its own, because the last line in the block is likely to change or new lines to be inserted before the brace.

(In an ideal world, my editor should optionally replace the line with the closing brace with a (coloured) hairline starting at the left indent of the block till the right edge of the windown.)

Maybe obvious from above: I am not a big fan of too much vertical whitespace. I'd forbid more than one blank line between logical blocks.


Enjoy, Have FUN! H.Merijn

sub foo {
    my @args = @_;

    unless (scalar @args) {
        warn "No args in foo!";
        return;
        }

    return join ':' => @args;
    }
[download]