I also believe in indented closing braces (and I don't care Larry disagrees). I feel strongly for indenting them, as that is IMHO the only logical way to do it.

sub foo {
    my @args = @_;
    unless (scalar @args) {
        warn "No args in foo!";
        return;
        }
    return join ':' => @args;
    }
[download]

This style is called Ratliff- or Banner-style.

Because braces are just syntactic sugar to keep a block together, it should visually also bind to the block, and not to the conditional. As the closing brace - or END in languages like PASCAL - is visually showing me the end of the block, it should obviously have the same indent as the block itself. An advantage is that the alignment of the closing brace with the block emphasizes the fact that the entire block is conceptually (as well as programmatically) a single compound statement.

In other words: I see the braces being part of the block, and as all statements inside a block share the same indentation, in my opinion the brace - being part of the block - should have the same indentation too.

• Indent width is 4, tabs are allowed (when set to 8). I prefer having it being spaces only, but as I cannot see the difference with good editors, I do not really care.
• Opening brace should be on the same line as the conditional
• Block should be indented
• Closing brace should have the same indent as the block

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.

> or END in languages like PASCAL - is visually showing me the end of the block, it should obviously have the same indent as the block itself.

> 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]

Cheers Rolf
_{(addicted to the Perl Programming Language :)
Wikisyntax for the Monastery}

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'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!

Optimising for fewest key strokes only makes sense transmitting to Pluto or beyond

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]

Yes, I would write that, and yes, it is essentially Whitesmiths.

I don't much care about perlstyle's recommendation of Larry's wishes unless they can demonstrate a compelling reason for that coding choice. "Because I say so" isn't a compelling reason, even from Larry! That said, as mentioned before, I do follow the herd in terms of my Perl coding style for the compelling reason that consistency in style on PerlMonks sidesteps some of the possible distractions from the real meat of discussions.