Beefy Boxes and Bandwidth Generously Provided by pair Networks
Do you know where your variables are?
 
PerlMonks  

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

by Tux (Canon)
on Aug 07, 2022 at 15:07 UTC ( #11145996=note: print w/replies, xml ) Need Help??


in reply to How has your coding style changed over the years?

The only things I can come up for things that changed over the past 40+ years:

  • sub foo {
    

    instead of

    sub foo
    {
    

    where the old style was mainly used because it made vi happy on the { and } navigation keys

  • Indentaion 6 to 4 spaces. That was when I stopped using Pascal and Basic

I know many will NOT agree with my style, but at least I am very consistent. *AND* I have an explanation for every guide I follow, which I cannot say for people leaving school and just follow the basic rules of their IDE.

Anyway, not having a space between the function name and the opening paren is a reasong for me to not use the language at all.

I've summed it all up on my style guide. I will not accept PR's that do not strictly follow that guide.

Whatever style you follow, do so consistently, otherwise maint will be a nightmare.

Oh, and I do care a single *** about leading tabs or spaces even if you mix them. I don't see them. My editor does the right thing.


Enjoy, Have FUN! H.Merijn

Replies are listed 'Best First'.
Re^2: How has your coding style changed over the years?
by GrandFather (Saint) on Aug 10, 2022 at 01:47 UTC
    *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?"

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

      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.


      🦛

        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

        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
Re^2: How has your coding style changed over the years?
by LanX (Sage) on Aug 07, 2022 at 16:18 UTC
    > Oh, and I do care a single * about leading tabs or spaces even if you mix them. I don't see them. My editor does the right thing

    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)

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

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

Log In?
Username:
Password:

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

How do I use this? | Other CB clients
Other Users?
Others musing on the Monastery: (3)
As of 2023-02-02 20:42 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    I prefer not to run the latest version of Perl because:







    Results (22 votes). Check out past polls.

    Notices?