*AND* I have an explanation for every guide I follow

This is the compelling statement for me. I'm sure most of the (in my view) nasty coding practices prevalent now are simply because "that's the way I was taught" or, even worse, "I never thought about it".

My primary guide is "format it like prose" - which speaks mostly to horizontal white space usage and use of blank lines to group blocks of related lines (paragraphs). A secondary guide is that stuff at the start of a line is much more important than stuff at the end of a line - which speaks to how "long" lines get wrapped and to what constitutes "long".

I use K&R for Perl because "everyone" does, but I can't think of any justification for it. Elsewhere (mostly C++) I indent curlies to the same level as the rest of the block they are part of. My justification is that a curly wrapped block of statements is semantically the same as a single statement and should be indented the same. In my mind the curlies are part of the block so ...

Would anyone care to suggest why K&R is compelling?"

I use 1TBS which is close to (or perhaps even what you were meaning by) K&R. It (opinion!) makes maximum use of space without sacrificing clarity and in my mind the end of a block statement being at the same indentation as the start of that statement makes perfect sense.

Elsewhere (mostly C++) I indent curlies to the same level as the rest of the block they are part of.

If you were to do the same in Perl would you write like this?

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

That is (or looks like) full Whitesmiths which I have seen on occasion in some Perl code but it just messes with my head. It also seems to go against this comment in perlstyle:

Regarding aesthetics of code lay out, about the only thing Larry cares strongly about is that the closing curly bracket of a multi-line BLOCK should line up with the keyword that started the construct. Beyond that, he has other preferences that aren't so strong ...

I am happy to adhere to Larry's wishes on this one.

---

🦛

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

Enjoy, Have FUN! H.Merijn

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.

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

If someone is using an indentation different to 4 you'll get ugly results. (That's actually a running gag in code sections posted here, because browsers still default to tab=8)

The only right thing your editor can do is reindenting all the code, which will result in a full diff when checking into version control.

And even with indent 4 calling untabify (or whatever it's called in vim) will cause unwanted diffs.

My strategy is to commit the untabified version first. But doing this everytime a colleague touched the file might get annoying.

So this question is of relevance when working in a team, IMHO. (And yes certainly YMMV)

(That's actually a running gag in code sections posted here, because browsers still default to tab=8)

this seems to have been fixed in the CSS or at least for Chrome

for my $x (@a) {
    print; # 1 tab
    print;     # 4 blanks
}
[download]