anshumangoyal has asked for the wisdom of the Perl Monks concerning the following question:

I have around 100 Perl file which I want to follow 80 chars per line rule. I tried using perltidy for the same. It works fine except that the print and die statements are indented wrongly. For a print:
print "-file Run Test Cases from this 'xlsm' File. Default += 'SanityTestCases.xlsx'.\n";
it changes:
print " -file Run Test Cases from this 'xlsm' File. Default = 'San +ityTestCases.xlsx'.\n";
Is there any other way i can make my code 80 characters indented automatically.

Replies are listed 'Best First'.
Re: Perl 80 Chars perl line Rule
by Corion (Pope) on Oct 16, 2012 at 08:36 UTC
    Q:\>perl -nle "print length" "-file Run Test Cases from this 'xlsm' File. Default = 'SanityT +estCases.xlsx'.\n"; 89

    The string itself is longer than 80 chars. It is very hard for a program to break up a string in a sensible and Perl-preserving manner, so you will have to break up these lines manually.

Re: Perl 80 Chars perl line Rule
by MidLifeXis (Monsignor) on Oct 16, 2012 at 12:02 UTC

    Also search for 'outdent' in the perltidy documentation. The string being longer than 80 characters is the main issue, and the behavior of the indentation is controlled by the outdent settings.


Re: Perl 80 Chars perl line Rule
by sundialsvc4 (Abbot) on Oct 16, 2012 at 13:14 UTC

    I wouldn’t hold fast to any sort of “rule,” which definitely to me smacks of the days in which we all used CRTs.   Especially not at the risk of unnecessarily disturbing [large blocks of ...] source-lines that presently work, and of also seriously damaging the revision-tracking capability of the source code control system (SCCS).   If, on a case-by-case basis, it appears that a block of code is inconsistent with its neighbors and therefore genuinely hard-to-read, then I would highlight that block of code and tidy it ... checking in the results (having made no other changes) immediately back into the SCCS, with an appropriate notation, “tidied this.”   (I strongly advocate keeping all such commits separate:   don’t change code and tidy it in the same commit.)

    P.S.:   I’m also not suggesting here that longer source-lines are somehow better.   In fact, “you young turks” should bear in mind that one day your optometrist is going to screw-up your glasses prescription, even to the point of getting the damm things so badly cut that the top half has a different focal-length than the bottom half ... bah!

      The rule is much older than you seem to think. Some of us still remember 80 column IBM punch cards. (Many versions of FORTRAN reserved the last eight of these for "sequence numbers")
        80 col IBM...

        ...and long after that, my first, personally-owned puter: O1 with a (or is memory failing along with my eyes) a 5-inch, 52 column screen.
            Ah, just rolling in the remembered joy of the DD and 80-col upgrades!