Hi all,

anshumangoyal asked how to reformat perl scripts to fit the 80 chars perl line rule (Perl 80 Chars perl line Rule). I'm asking:

What do you think. Is that rule still meaningful? We have huge 16:9 monitors. Why should a line not be longer?

I have the most trouble following the rule with strings I want to print if this string is more than 80 chars long. I think it's tedious to concatenate two substrings only to follow that rule. How do you handle long (one line) strings?

Updated: Insert of link. Thanks to MidLifeXis for the hint.

Best regards

  • Comment on 78/80 chars perl line still a meaningful rule

Replies are listed 'Best First'.
Re: 78/80 chars perl line still a meaningful rule
by Ratazong (Monsignor) on Oct 16, 2012 at 09:58 UTC

    Hi McA!

    Despite having not only one, but two wide monitors, I still think its a good idea to keep lines in code short. That does not mean a hard cut on 80 characters, but to take care that it is not much longer. I have the following reasons

    • I prefer reading "top-down" to "left-right" ... and that includes code
    • my screen is usually filled with windows, so its good to have them side-by-side and still being able to see all of the code
    • in some rare cases I print code ... and then I have a limit of characters per line (otherwise it looks akward...)
    Am I just too old-fashioned?

    HTH, Rata
      ...and e.g. file comparison tools, which I use often to see what has changed. Two code windows side-by-side mean 160 characters already.

      Not to mention, the optimal width for reading prose is somewhere around 60 characters per line. The eyes don't need to track so far back when they reach end of the line and so on. (I'm sure there's research on this I can't bother to conjure up right now.) (See also: newspapers, magazines. They break their text into columns, too.)

      Usually when I need to print text, I print two pages per sheet (A4) just to get the line lengths to something satisfactory. It also tends to save a bit of paper...

      Anyway, code. My stance is that you can't achieve clean code unless you keep your line length under 80 characters. The widescreen monitor argument? Either put multiple code listings side by side, or pivot your monitor. 10:16 or 9:16 doesn't seem so wide anymore, does it?

      (...those cheap monitors that use TN panels don't pivot so well...)

Re: 78/80 chars perl line still a meaningful rule
by talexb (Canon) on Oct 18, 2012 at 19:23 UTC

    It's a simple question, with, for me, a complicated answer. It boils down to

    • Make the code easy to read and comprehend;
    • Make the code easy to maintain; and
    • Make the code easy to print out.

    Reading and Comprehension are important points: if there are multiple lines much longer than 80 characters, the eye can't take it all in, and the head has to move as well. The eye's visual acuity is actually quite limited, but the brain does an excellent job of pretending that it's better than it is. As the line of code gets longer, it gets harder to find where the beginning of the next line is.

    Maintaining code, once you comprehend it, is vital. And it could be that you're not on your favourite workstation with multiple gigantic screens -- you might be limited to a 25x80 screen. Having long lines cut off or wrapped can be quite irritating. (I've just been working on some scripts within Jenkins, editing in dialog boxes, and it's difficult to see where a line is a continuation.)

    Getting a hard copy of your code can be quite useful -- but that's for naught if the print function either cuts the long lines or wraps them where you don't want it to. It's much better to do your own wrapping (I use gq{ in vim, for example) and have it display and print out correctly. Yes, the file will be longer -- too bad. :)

    Alex / talexb / Toronto

    "Groklaw is the open-source mentality applied to legal research" ~ Linus Torvalds

      I agree with that!

      And may I add that consistency in your indentation is more important than the length of your lines.

      There are no stupid questions, but there are a lot of inquisitive idiots.
Re: 78/80 chars perl line still a meaningful rule
by sundialsvc4 (Abbot) on Oct 16, 2012 at 14:18 UTC

    Thirty years ago I would have given you a different answer.   Today, I think that most source-code lines already do fit within a “reasonable” length, such that, if they don’t, they are probably already hard-to-read for reasons other than just the number of characters in the line.

    A very common example is:   subroutine calls.   You can have very long lists of parameters there, sometimes.   Although I tend to prefer using a single hashref instead, “existing-code is what existing-code is.”   That’s where you encounter length ... and a choice site for breaking the call into multiple lines, perhaps with comments.   Even so, what you are trying to simplify is not so much “scrolling from left to right,” but “counting commas.”   Ultimately you are trying to improve at-a-glance clarity, not merely to reduce line length.

    Character strings:   write several shorter literals and concatenate.   Better yet, write a shorter error-message to begin with, because you’d prefer that the user actually reads it.

    So, to me, this isn’t a “rule,” i.e. strictly concerned with length and/or saying that you have actually made the code “better” just by folding the lines.

    As I said in the other post, you can really hose up a file, in terms of the source-code control system, if you reformat the whole thing, because you have just wiped-out the history of source-code changes to a particular area.   Hence, I advocated selective reformatting of particular problem areas (with prior agreement from your management and from all of your colleagues!) and checking-in those revisions separately, having made no other changes in the same commit.   Sometimes, the continuity of per-line history through a particular hot-spot is more important than [e.g. as a result of all these many changes over time] “it stinks.”

Re: 78/80 chars perl line still a meaningful rule
by SuicideJunkie (Vicar) on Oct 16, 2012 at 16:27 UTC

    I just skimmed through some code I'd written recently on my netbook and checked the line lengths. (not counting indentation, currently set to tab width of 2)

    • Most of the "short" lines are 40-50, as there are lots of two level deep hash keys with decent names involved.
    • Longer lines go 80-120, taking up half the screen with math and hash keys, or comments.
    • The longest lines hit 200, and tend to be die/warn/confess strings with interpolated hash lookups and a post condition.
      • eg: confess "Insufficent data in X from {hash lookup} through {hash lookup} source data file {hash lookup}" unless {condition};

    I'm happy with the 200 char confess, because the important bits of it are all in the first 40-60 characters. Then there's a bunch of hash lookups which only matter after they've been interpolated into an error message. Then comes the conditions, which should have been clear from the English in the first 40-60 characters. It's a netbook, so why waste vertical space on unimportant stuff like that?

    Note: I am not using a fixed width font, so the lines appear narrower than they otherwise would be.

      $condition or confess sprintf( "Insufficent data in X from %s through %s source data file %s", $hash{lookup1}, $hash{lookup2}, $hash{lookup3}, );
      perl -E'sub Monkey::do{say$_,for@_,do{($monkey=[caller(0)]->[3])=~s{::}{ }and$monkey}}"Monkey say"->Monkey::do'

      Good morning,

      thank you for looking at your code.

      One thing I'm really intersted in is how would the others break up and concatenate these long "confess-strings" if they don't want to violate the 80cpl rule?

      Best regards

        perltidy does

        confess "Insufficent data in X from {hash lookup} through {hash lookup} so +urce data file {hash lookup}" unless $condition;
        which seems reasonable, although these days I prefer "condition or" to "unless"
        $condition or confess "Insufficent data in X from {hash lookup} through {hash lookup} source + data file {hash lookup}";

        I've tried my hand at concatenation

        $condition or confess "Insufficent data in X from {hash lookup} " . "through {hash lookup} source data file {hash lookup}";
        And I it is pleasing to the eye, but I wouldn't do that by hand typing (editor IDE should handle it automagically). This also makes searching source code slightly more keyboard clicks but its not a deal breaker for me.

        I also like

        $condition or confessn "Insufficent data in X from {hash lookup} through {hash lookup} source data file {hash lookup}";
        where confessn would do some newline squashing

        But mostly I just let it go past 80 chars cause is the least hassle and works with all editors :)

        # Given. confess "Insufficent data in X from {hash lookup} through {hash lookup +} source data file {hash lookup}" unless {condition};

        I prefer sprintf when there are more than 1 or 2 simple variables are involved. Using sprintf sans () with post condition check is awkward, so used or. I would use map or hash slice if the 3 instances refer to the same hash (reference). First argument to sprintf would be on single line.

        {condition} or confess sprintf "Insufficient data in X from %s through %s source da +ta file %s" , {hash lookup} , {hash lookup} , {hash lookup} ;

        For 'confess', it is trivial:

        % perl -MCarp=confess -e"confess 'this ', 'is split'" this is split at -e line 1

        If it isn't something that can deal with a list of strings, then I use join the vast majority of the time (because '.' has lousy precedence for such, 'sprintf' quickly leads to action-at-a-distance, '<<' can't be sanely indented, etc.).

        - tye        

Re: 78/80 chars perl line still a meaningful rule
by tobyink (Abbot) on Oct 16, 2012 at 21:00 UTC

    Generally speaking I treat 76 characters as a "soft limit". I try to keep lines under that, and wrap them if they're going to be longer. However, sometimes the wrapped version would be less legible than the original, so I'll tolerate lines of 80, 90 or even 100 characters.

    perl -E'sub Monkey::do{say$_,for@_,do{($monkey=[caller(0)]->[3])=~s{::}{ }and$monkey}}"Monkey say"->Monkey::do'
Re: 78/80 chars perl line still a meaningful rule
by parv (Priest) on Oct 16, 2012 at 10:33 UTC

    I much prefer 4:3 screens instead of stupid rage of 16:9 (16:10 is only a slight improvement). I do not have a choice though than to deal with squishy screens at work and at home. Further, you may have a huge monitor(s), I do not.

    I use large font sizes (~20 pt in browser, ~18 px monospaced font in xterm); on MS Windows I increase the dpi instead by about 25%.

    I generally follow 80-character line length limit. When using two vertical windows (as in vim :vsplit or vimdiff) even that limit becomes too large. I often not care for the limit in case of a longer string. Then again I tend to fragment a string around punctuation marks, (semi)independent clauses, after each sentence, etc. if possible.

    When printing (in monospaced font at size 14 pt), limit is around 68 characters. If I were to generally use a limit larger than 80-character, a (temporary) reformatting would require more time.

Re: 78/80 chars perl line still a meaningful rule
by ww (Archbishop) on Oct 19, 2012 at 03:54 UTC
    Count the chars in a typical line in a newspaper column. It will vary a bit with the format of the paper, but generally won't exceed 40-50.

    There may be a (retro-justification) reason for that: a good deal of research on comprehensibility identifies something in the 40-60 range as optimal (given the head and eye movement issues cited by talexb) and that isn't far off from AM's offering at Re^2: 78/80 chars perl line still a meaningful rule.

    But code is NOT prose and that fact may be an argument for even shorter lines in code (allowing for occasional longer ones if those don't split reasonably. Generally, tho, I find that a 2 or 3 char indent on an extended line (ie, one with a CR that isn't really supposed to end the line).

Re: 78/80 chars perl line still a meaningful rule
by space_monk (Chaplain) on Nov 04, 2012 at 12:59 UTC
    It's not a law, but it is sound advice, which should be broken only at need.

    The width of wider screens is often taken up by IDE tools or having multiple windows open.

    “Rules are for the obedience of fools and the guidance of wise men" - Douglas Bader

Re: 78/80 chars perl line still a meaningful rule
by greengaroo (Hermit) on Oct 19, 2012 at 17:54 UTC

    I try to keep my line short, but I am not going to cut my line in two if it is a bit longer then 80 characters. I would if it is a very long IF or WHILE statement with lots of conditions, or if I populate a HashRef with data, but that's it.

    There are no stupid questions, but there are a lot of inquisitive idiots.

      Don't hate the player hacker, hate the game code base.

      Update: this is in ref to node #10x6 which was snatched by squatting on the URI: http://perlmonks.org/?parent=999999;node_id=3333. Update 2: thinko; s/player/game/.

        Your Mother:

        Gratz! You have the winning node!


        When your only tool is a hammer, all problems look like your thumb.

            Don't hate the player hacker, hate the player code base.

        All your code base are belong to us.

        Peter L. Berghold -- Unix Professional
        Peter -at- Berghold -dot- Net; AOL IM redcowdawg Yahoo IM: blue_cowdawg