Beefy Boxes and Bandwidth Generously Provided by pair Networks
We don't bite newbies here... much
 
PerlMonks  

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

by hippo (Bishop)
on Aug 10, 2022 at 10:45 UTC ( [id://11146074]=note: print w/replies, xml ) Need Help??


in reply to Re^2: How has your coding style changed over the years?
in thread How has your coding style changed over the years?

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; }

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.


🦛

Replies are listed 'Best First'.
Re^4: How has your coding style changed over the years?
by Tux (Canon) on Aug 10, 2022 at 11:03 UTC

    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; }

    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

      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

      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

        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; }
Re^4: How has your coding style changed over the years?
by GrandFather (Saint) on Aug 12, 2022 at 03:47 UTC

    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

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://11146074]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others scrutinizing the Monastery: (5)
As of 2024-03-29 08:51 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found