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	[reply]
Re^2: 78/80 chars perl line still a meaningful rule by grizzley (Chaplain) on Oct 16, 2012 at 10:16 UTC
...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.	[reply]
Re^2: 78/80 chars perl line still a meaningful rule by Anonymous Monk on Oct 16, 2012 at 19:48 UTC
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...)	[reply]
Re: 78/80 chars perl line still a meaningful rule by talexb (Chancellor) 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	[reply] [d/l]
Re^2: 78/80 chars perl line still a meaningful rule by greengaroo (Hermit) on Oct 19, 2012 at 17:56 UTC
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. -- greengaroo	[reply]
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.” /p
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.	[reply] [d/l]
Re^2: 78/80 chars perl line still a meaningful rule by tobyink (Canon) on Oct 18, 2012 at 16:26 UTC
`$condition or confess sprintf( "Insufficent data in X from %s through %s source data file %s", $hash{lookup1}, $hash{lookup2}, $hash{lookup3}, );` [download] `perl -E'sub Monkey::do{say$_,for@_,do{($monkey=[caller(0)]->[3])=~s{::}{ }and$monkey}}"Monkey say"->Monkey::do'`	[reply] [d/l]
Re^2: 78/80 chars perl line still a meaningful rule by McA (Priest) on Oct 17, 2012 at 07:35 UTC
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 McA	[reply]
Re^3: 78/80 chars perl line still a meaningful rule by Anonymous Monk on Oct 17, 2012 at 08:11 UTC
perltidy does `confess "Insufficent data in X from {hash lookup} through {hash lookup} so +urce data file {hash lookup}" unless $condition;` [download] 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}";` [download] 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}";` [download] 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}";` [download] 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 :)	[reply] [d/l] [select]
Re^4: 78/80 chars perl line still a meaningful rule by McA (Priest) on Oct 17, 2012 at 08:24 UTC
Re^3: 78/80 chars perl line still a meaningful rule by Anonymous Monk on Oct 17, 2012 at 09:32 UTC
`# Given. confess "Insufficent data in X from {hash lookup} through {hash lookup +} source data file {hash lookup}" unless {condition};` [download] 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} ;` [download]	[reply] [d/l] [select]
Re^4: 78/80 chars perl line still a meaningful rule by Anonymous Monk on Oct 18, 2012 at 16:12 UTC
Re^3: 78/80 chars perl line still a meaningful rule (,) by tye (Sage) on Oct 17, 2012 at 13:37 UTC
For 'confess', it is trivial: `% perl -MCarp=confess -e"confess 'this ', 'is split'" this is split at -e line 1` [download] 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	[reply] [d/l]
Re: 78/80 chars perl line still a meaningful rule by tobyink (Canon) 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'`	[reply]
Re: 78/80 chars perl line still a meaningful rule by parv (Parson) 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.	[reply]
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).	[reply]
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	[reply]
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. -- greengaroo	[reply]
Re^2: 78/80 chars perl line still a meaningful rule by Your Mother (Archbishop) on Oct 19, 2012 at 17:54 UTC
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/.	[reply] [d/l]
Re^3: 78/80 chars perl line still a meaningful rule by talexb (Chancellor) on Oct 19, 2012 at 20:13 UTC
Reminds me of a Peter Gabriel quote, "The technical term for this .. is 'cheating'" 1 :) :) Alex / talexb / Toronto "Groklaw is the open-source mentality applied to legal research" ~ Linus Torvalds 1. http://hoardedordinaries.wordpress.com/2008/05/12/cheating-2/	[reply]
Re^4: 78/80 chars perl line still a meaningful rule by roboticus (Chancellor) on Oct 19, 2012 at 20:32 UTC
Re^3: 78/80 chars perl line still a meaningful rule by roboticus (Chancellor) on Oct 19, 2012 at 17:55 UTC
Your Mother: Gratz! You have the winning node! ...roboticus When your only tool is a hammer, all problems look like your thumb.	[reply]
Re^3: 78/80 chars perl line still a meaningful rule by blue_cowdawg (Monsignor) on Oct 19, 2012 at 18:41 UTC
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	[reply]


Perl Monk, Perl Meditation
	PerlMonks