in reply to Best practices and any way to have Perl Tidy clean it up

G'day walkingthecow,

"I am wondering what the Perl Best Practices are with regards to long fields applied to an object, and if there is any way for Perl Tidy to automatically clean those up."

There's a few Perl Best Practices that could apply. Here's some that identify problems:

Line Lengths
Use 78-column lines. (pp.18-19) [So you're not doing that.]
Indentation
Use four-column indentation levels. (pp.19-20) [And you're not doing this either.]
Tabs
Indent with spaces, not tabs. (pp.20-22) [That could be an issue. Are you doing this one?]

Here's some that suggest solutions:

Multiline Strings
Lay out multiline strings over multiple lines. (pp.60-61)
Here Documents
Use a heredoc when a multiline string exceeds two lines. (p.61)
Heredoc Indentation
Use a "theredoc" when a heredoc would compromise your indentation. (pp.61-62)
Heredoc Terminators
Heredoc Quoters
Another two to read if you go with a heredoc solution. (pp.62-65)
Automated Layout
Enforce your chosen layout style mechanically. (pp.33-35) [Talks about perltidy and provides a .perltidyrc at the end.]

-- Ken

Replies are listed 'Best First'.
Re^2: Best practices and any way to have Perl Tidy clean it up
by Laurent_R (Canon) on Apr 13, 2013 at 22:41 UTC

    With all due respect to Damian Conway and to his absolutely excellent book (whose recommendations I do follow on a number of items, well, most of them), and I certainly don't claim to challenge his authority, I still have to disagree.

    The line length and the tab recommendations are, to say the least, debatable (at least in my view).

    I had dinner last Monday with Curtis "Ovid" Poe and brian de foy in Paris (social setting with the Perl Mongers in Paris), and we discussed briefly these matters, my feeling is that both of them agreed that using spaces rather than tabs is not the best idea.

    To brian and Curtis: if I misrepresented what you said in any way (I don't think I did, but just in case), sorry about that, I did not mean that.

      I wasn't advocating the use of any of those recommendations. This was merely a response to the OP's request: "... wondering what the Perl Best Practices are ...". These are just those I thought applicable to the situation at hand; there may be others.

      For what it's worth, I don't use Line Lengths but I do use Indentation and Tabs; I don't recall ever using Multiline Strings (but it seems sensible enough); I do use heredocs and theredocs; I don't use perltidy.

      -- Ken

      Out of curiosity, do you know what their objections to indenting with spaces was? I've always found it significantly more reliable and manageable than using tabs. I'd be curious about arguments to the contrary.

      Christopher Cashell

        PBP advocates using spaces, so their objection, such as it is, is to the use of tabs.

        The Tabs best practice is one that I use: no "arguments to the contrary" from me.

        I'm sure others with different preferences will provide their views on the subject.

        -- Ken

      my feeling is that both of them agreed that using spaces rather than tabs is not the best idea

      Out of curiosity, do you know what their objections to indenting with spaces was? Or what the advantages of tabs are?

      I've always found spaces to be more reliable and manageable than using tabs. I'd be curious about arguments to the contrary.

      Christopher Cashell
Re^2: Best practices and any way to have Perl Tidy clean it up
by walkingthecow (Friar) on Apr 14, 2013 at 15:22 UTC
    Thank you! That's pretty much exactly what I was looking for. I actually use the -pbp (perl best practices) flag with Perl Tidy, which sets 78-column lines for my scripts, but does not touch object params for some reason. So, 99% of my script is shortened down to 78-column lines, then I have these stragglers, these long lines that are object params. Guess I will have to do it manually (no big deal) to fit within the suggestions given above. The -pbp flag I believe sets all options to that which you find in the perltidyrc file provided by the Perl Best Practices book. Seems a little known option (it's not even in --help output), but something worthwhile knowing. Again, thank you for your excellent response.

      A string (e.g. "a string") is a constant. You can't modify it directly in code. You may well have a very good reason for positioning characters within the string. It would inappropriate for perltidy (or other similar software) to modify a constant you've coded. Even without strict and warnings, attempting to modify a constant value is a fatal error:

      $ perl -e '"abc" =~ s/c$//' Can't modify constant item in substitution (s///) at -e line 1, at EOF Execution of -e aborted due to compilation errors.

      Ditto for numbers:

      $ perl -e '2++' Can't modify constant item in postincrement (++) at -e line 1, near "2 +++" Execution of -e aborted due to compilation errors.

      Chapter 2 of PBP is devoted to Code Layout. While the focus is obviously on laying out Perl code, many of the suggestions would apply equally to other languages: this might provide a few hints for your SQL.

      -- Ken