|
Re: To <=80 char code line length or not
by johngg (Canon) on Jun 07, 2018 at 22:30 UTC
|
For the first seven or so years of my career I was a Fortran programmer so I was used to a 72 character limit so moving to 80 characters seemed like a luxury. I still try to keep code lines under 80 characters as it avoids problems with line wrapping and, to my eye, is neater and easier to read. I try where possible to set tools up with a longer default line length but still limit my code to less than 80. I'm also an advocate of plenty of white space and will write my $var = $hash{ key }->[ $sub ]; rather than my $var=$hash{key}->[$sub];. Again, it is easier to see what is going on, at least to my old eyes.
| [reply]
[d/l]
[select] |
Re: To <=80 char code line length or not
by tobyink (Canon) on Jun 08, 2018 at 09:12 UTC
|
I tend to treat it as a soft limit. If I line is more than 80 characters, I see if I can break it up, or wrap it onto multiple lines. But if doing so would make it less clear, I keep the long line.
| [reply] |
Re: To <=80 char code line length or not
by BrowserUk (Patriarch) on Jun 07, 2018 at 23:16 UTC
|
I started exceeding that notional 80-char barrier the first time I got a VT-100 (circa.'79) with its 132 wide mode.
These days my code generally stays within 132 wide, as my 21" (1920x1080) monitor allows me to have 2, 132x64 (using 10-point Consolas) tiles side-by-side, but it is in no way sacrosanct. If the structure of the code is such that it feels right to go longer, I do.
I find the justifictions for sticking rigidly to 80/72/64 completely bogus. If your terminal software won't let you use more than 80 characters, get better terminal software. If your editor doesn't allow you to configure it to not wrap at some stupid limit; get a better editor. And the whole idea of structuring code into old fashioned broadsheet newspaper columns makes no sense -- no one 'reads' code like a newspaper article or novel.
And the using the kind of de-structuring that is epitomised by the Perl sources, in order to comply with such outdated, arbitrary limits, is tantamount to a criminal act.
The tokens that make up the lines of source code are only (actually, probably less than) half the story, the structure of the code is equally, if not more important; and good -- or at least consistent -- indentation tells you more at a glance about that structure, than any amount of pouring over the code whilst looking at it through a vertical letterbox slot ever will.
Collapsing levels of indentation so as to avoid spilling over pointless line on the right of the screen, is like removing the staffs from sheet music.
At this point I want to lay into interleaving pod with code; but I better shut up :)
With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
In the absence of evidence, opinion is indistinguishable from prejudice.
Suck that fhit
| [reply] |
|
|
| [reply] |
Re: To <=80 char code line length or not
by LanX (Saint) on Jun 07, 2018 at 22:39 UTC
|
I think it's a lucky coincidence that the console width is near the optimal width for eye movement.
that means
- not loosing current right line while reading
- easily jump to the following line
I'm pretty sure this has already been investigated by scientists, measuring milliseconds and eye tracking.
Now is code not prose where you fill all columns,
it has plenty of whitespace on both sides, it's less likely to lose track.
(Not talking about POD which is prose, and really should abide to 80)
And if you use a fixed comment column like I do, you are easily forced to break the text if the comment gets longer than 3 words.
So I'm not too dogmatic about the 80 limit in my team, but above
100 it gets critical and 120 is the absolut limit.
Perltidy has very good options to handle most of this, unfortunately this is mostly ignored in heated discussions.
| [reply] |
|
|
I think it's a lucky coincidence that the console width is near the optimal width for eye movement.
I think it's an excellent design choice that the console width is near the optimal width for eye movement.
While it's not a cast-iron rule, I do tend to keep code lines under 80 chars. It's easier to read, easier to debug, prints neatly on pretty much any output device and encourages critical thinking. All IMHO. For collaborative code, perltidy is the winner.
perlcritic (at least version 1.125) seems perfectly happy with absurdly long lines, which is somewhat surprising.
| [reply] |
|
|
Maybe I'm repeating myself, but the problem here is that code is actually a twocolumn format!
(At least mine which IS often documented to the right.)
So it also depends on the documentation style, one can have a 80 column model and reserve comments to separate lines.
edit: I agree about perltidy , which has enough option flexibility to pacify a quarreling team. ;-)
| [reply] |
|
|
> Perltidy has very good options to handle most of this
Unfortunately, the devil is in the detail. At work, we tried to run it over our codebase: where the formatting was previously complex and provoked discussions, the automated results were plain wrong, as the meaning of the code was lost.
($q=q:Sq=~/;[c](.)(.)/;chr(-||-|5+lengthSq)`"S|oS2"`map{chr |+ord
}map{substrSq`S_+|`|}3E|-|`7**2-3:)=~y+S|`+$1,++print+eval$q,q,a,
| [reply]
[d/l] |
|
|
| [reply] |
|
|
|
|
I think it's a lucky coincidence that the console width is near the optimal width for eye movement... I'm pretty sure this has already been investigated by scientists,
I bet -- in fact I'll pretty much guarantee -- that you cannot cite one authoritative reference for that piece of pseudo-science. (You'll probably claim that you're "too busy", or it's "too hard to do from your phone", like normal.)_
It doesn't even stand up to the most casual of thought processes.
- 1234 6789 1234 6789 1234 6789 1234 6789 1234 6789 1234 6789 1234 6789 1234 6789
How much wood could Chuck Woods' woodchuck chuck, if Chuck Woods' woodchuck could and would chuck wood? If Chuck Woods' woodchuck could and would chuck wood, how much wood could and would Chuck Woods' woodchuck chuck? Chuck Woods' woodchuck would chuck, he would, as much as he could, and chuck as much wood as any woodchuck would, if a woodchuck could and would chuck wood.
- 1234 6789 1234 6789 1234 6789 1234 6789 1234 6789 1234 6789 1234 6789 1234 6789
How much wood could Chuck Woods' woodchuck chuck, if Chuck Woods' woodchuck could and would chuck wood? If Chuck Woods' woodchuck could and would chuck wood, how much wood could and would Chuck Woods' woodchuck chuck? Chuck Woods' woodchuck would chuck, he would, as much as he could, and chuck as much wood as any woodchuck would, if a woodchuck could and would chuck wood.
- 1234 6789 1234 6789 1234 6789 1234 6789 1234 6789 1234 6789 1234 6789 1234 6789
How much wood could Chuck Woods' woodchuck chuck, if Chuck Woods' woodchuck could and would chuck wood? If Chuck Woods' woodchuck could and would chuck wood, how much wood could and would Chuck Woods' woodchuck chuck? Chuck Woods' woodchuck would chuck, he would, as much as he could, and chuck as much wood as any woodchuck would, if a woodchuck could and would chuck wood.
- 1234 6789 1234 6789 1234 6789 1234 6789 1234 6789 1234 6789 1234 6789 1234 6789
How much wood could Chuck Woods' woodchuck chuck, if Chuck Woods' woodchuck could and would chuck wood? If Chuck Woods' woodchuck could and would chuck wood, how much wood could and would Chuck Woods' woodchuck chuck? Chuck Woods' woodchuck would chuck, he would, as much as he could, and chuck as much wood as any woodchuck would, if a woodchuck could and would chuck wood.
- 1234 6789 1234 6789 1234 6789 1234 6789 1234 6789 1234 6789 1234 6789 1234 6789
How much wood could Chuck Woods' woodchuck chuck, if Chuck Woods' woodchuck could and would chuck wood? If Chuck Woods' woodchuck could and would chuck wood, how much wood could and would Chuck Woods' woodchuck chuck? Chuck Woods' woodchuck would chuck, he would, as much as he could, and chuck as much wood as any woodchuck would, if a woodchuck could and would chuck wood.
- 1234 6789 1234 6789 1234 6789 1234 6789 1234 6789 1234 6789 1234 6789 1234 6789
How much wood could Chuck Woods' woodchuck chuck, if Chuck Woods' woodchuck could and would chuck wood? If Chuck Woods' woodchuck could and would chuck wood, how much wood could and would Chuck Woods' woodchuck chuck? Chuck Woods' woodchuck would chuck, he would, as much as he could, and chuck as much wood as any woodchuck would, if a woodchuck could and would chuck wood.
- 1234 6789 1234 6789 1234 6789 1234 6789 1234 6789 1234 6789 1234 6789 1234 6789
How much wood could Chuck Woods' woodchuck chuck, if Chuck Woods' woodchuck could and would chuck wood? If Chuck Woods' woodchuck could and would chuck wood, how much wood could and would Chuck Woods' woodchuck chuck? Chuck Woods' woodchuck would chuck, he would, as much as he could, and chuck as much wood as any woodchuck would, if a woodchuck could and would chuck wood.
- 1234 6789 1234 6789 1234 6789 1234 6789 1234 6789 1234 6789 1234 6789 1234 6789
How much wood could Chuck Woods' woodchuck chuck, if Chuck Woods' woodchuck could and would chuck wood? If Chuck Woods' woodchuck could and would chuck wood, how much wood could and would Chuck Woods' woodchuck chuck? Chuck Woods' woodchuck would chuck, he would, as much as he could, and chuck as much wood as any woodchuck would, if a woodchuck could and would chuck wood.
- 1234 6789 1234 6789 1234 6789 1234 6789 1234 6789 1234 6789 1234 6789 1234 6789
How much wood could Chuck Woods' woodchuck chuck, if Chuck Woods' woodchuck could and would chuck wood? If Chuck Woods' woodchuck could and would chuck wood, how much wood could and would Chuck Woods' woodchuck chuck? Chuck Woods' woodchuck would chuck, he would, as much as he could, and chuck as much wood as any woodchuck would, if a woodchuck could and would chuck wood.
With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
In the absence of evidence, opinion is indistinguishable from prejudice.
Suck that fhit
| [reply] |
|
|
Surprisingly spurious rebuttal. I was a typographer before I was a programmer and agree with Line length. I checked about a dozen other resources and found *only* agreement with, or within the bounds of, 45 to 75 characters as optimal reading length. Add in the need for extra spacing and punctuation in programming, you get close enough to 80.
| [reply] |
|
|
|
|
> that you cannot cite one authoritative reference for that piece of pseudo-science.
Well please define "authoritative reference", psychologists will normally argue from study to study about methodology and sample. (for instance I'm dyslexic and color blind, did they cover my group in their sample?)
Anyway ...
I was referring from memory (I earned my first money hacking for a DTP product) about what I read about typographical Line_length which is at least normatively set to between 45 and 75 characters.
Normative means we got used to it, like we got used to a decimal system, which is not necessarily the objective best of all parallel universes.
Additionally there are subjective preferences:
60% of respondents indicated a preference for either the shortest (35 CPL) or longest (95 CPL) lines used in the study. At the same time, 100% of respondents selected either one of these quantities as being the least desirable *
Which seems to indicate that around middle you'll have the least discussions with annoyed users.
Anyway all these studies deal - like I said - with prose in paragraphs, not intended code, and I said I'm not dogmatic here.
Code is actually two column text, because comments are best aligned
Regarding your question: So the above WP article lists some studies, do I need to copy&paste them and are they "authoritative" enough? ²
Question: what is the blind text in different sizes supposed to tell us???
*) Hmm ... wondering what dyslexic guys prefer...
²) NB: the German WP article highlights the importance of line spacing while the English strangely doesn't seem to mention it.
| [reply] |
|
|
|
|
|
|
|
|
|
|
Re: To <=80 char code line length or not
by huck (Prior) on Jun 07, 2018 at 22:54 UTC
|
My first programming experience was in APL/1500 via a 2741. APL could have arbitrarily long lines that would just wrap.
Next i went to cards and the FORTRAN limit of 66 for the code (5 for label, one for comment, 66 for code, 8 for seq). As i moved to dumb terminals, decwriters, IBM 2780/3780/3270/3279, Tek4010/4014, and others the 80 char limit still made sense. But these days i have migrated up, a max of 120 seems common, sometimes 130 or 140. My default window size is 120, and sometimes get a left/right slider. But i try to keep most of the code under 80. I find its lines with lots of static text that grow past that.
But i see nothing wrong in keeping it below 80, as it does make it easier to read and enforces a cleaner design to the code. Long lines of code, can be hard to follow
| [reply] |
Re: To <=80 char code line length or not
by rminner (Chaplain) on Jun 08, 2018 at 21:56 UTC
|
A religious discussion in the monastery. How fitting :).
For me it boils down to readability.
Heavily indented, or very long code lines tend to be harder to read for me.
I therefore try to stay below 80 chars linewidth.
If it serves readability, i will however also go beyond the 80 chars.
| [reply] |
Re: To <=80 char code line length or not (focus)
by shmem (Chancellor) on Jun 08, 2018 at 14:08 UTC
|
While the 80 char limit may have its origin in widely accepted typesetting conventions for books with flowing text, combining book size, font size, line length and line number, those containing poetry leave the most part of their pages blank.
Reading flowing text, long lines make it difficult to return to the start of the following line after reaching the current line ending, which makes me memorize the current lines starting block of 1-2 lines before and after the current one, which is is annoying and hinders my flowing comprehension of what I am reading, and the limit of chars per line at which that orientation support begins to occur seems to be dependant on other factors like line margin, font, topic and so on, and - of course - also on the amount of information expressed and the numbers of sentences and sub-sentences being involved in that expression. Qed.
But code is neither flowing text nor poetry. Readability of code follows a whole bunch of different or additional factors.
An important one is proper variable naming. I think the most important one is focus - horizontally, vertically or block-wise. A simple transforming subroutine with a good name consisting of a single statement, sporting map, grep, sort, referencing and de-referencing with proper variable names and sensible spacing can easily be longer than 80 chars, whilst being just a macro which could be inlined. It depends of your own reading/writing habits and that of your team and/or audience whether you break that up into multiple lines.
Most of the bible prints I have seen are typeset with a very small font and 3-4 columns per page, so as to narrow the focus to just the holy sentence at hand, which purportedly helps to induce the "alpha wave" mode of the brain and protects from seeing the bigger picture. Nice trick.
So - as always, it depends, and TIMTOWTDI. I could, for instance, format my code left aligned, and the comments right aligned, and read either top down without distraction. Or just center the core of a subroutine after conditionals resolving, and before wantarray resolution. Or else.
Maybe we'll get editors some day which permit zooming in and out of projects for proper focus, as we already can do with online maps. We could then zoom into bugs until they fill the whole screen.
The 80 columns restriction is a thing of the past, and while the convention lives on for hysterical raisins, software or coding standards which enforce that restrictions for no other reasons than "well, it's been like that and therefore we continue doing it like that" is just annoying. Take the results from the ldapsearch(1) utility from openLDAP which splits lines after 78 chars, forcing reassembly of lines for further processing. There's absolutely no reason to do such a thing except for the holy cow "backward compatibility", and it forces you to filter the output with e.g. perl -p00 -e 's/\n //g' which is silly.
I'm formatting with "proper" indentation and in a way which looks fitting to me (except in python); for those yelling at me after the fact I have perltidy.
perl -le'print map{pack c,($-++?1:13)+ord}split//,ESEL'
| [reply]
[d/l] |
Re: To <=80 char code line length or not
by Laurent_R (Canon) on Jun 08, 2018 at 22:41 UTC
|
I am also old enough to have known line limits at 80 characters or even less.
With today's hardware, we usually have 16/9 screens, I don't see any reason to stick to such small line lengths.
Most of my code lines are probably much less than 80 characters, but, yet, I do not see any reason why this should always be so because of hardware standards dating from three decades ago. And I do write from time to time code lines that are much longer (say 132 characters, perhaps occasionally even longer).
One very important point in my view: when looking at a piece of code (say one specific subroutine): I like to see it entirely on my screen. The limitation is often vertical, rather than horizontal. And it is often much easier to see it all on just one screen with a longer line length. Especially with today's screens.
| [reply] |
Re: To <=80 char code line length or not
by Your Mother (Archbishop) on Jun 08, 2018 at 11:11 UTC
|
Just chiming in to agree with most of what everyone else said. I like 70/72 as well but it is quickly not enough with nested indention; even 80 isn't enough to my eye sometimes. I let the autoformatting do its job and correct it where I think it's more legible on one line.
I also don't care when it comes to raw strings if they are 500+ characters long. I never have to read them so legibility doesn't come into it.
| [reply] |
Re: To <=80 char code line length or not
by Ea (Chaplain) on Jun 11, 2018 at 14:09 UTC
|
I see comments on how with today's wide-screen monitors that you can fit more code on the screen.
Does nobody use a vertical screen to code? I've got 2 monitors, one rotated 90° so that I have the option of seeing twice as many lines when I'm writing modules. Most of my lines aren't long and splitting lines at semantic points gives me the option of commenting out a piece of a line in development.
Ea
Sometimes I can think of 6 impossible LDAP attributes before breakfast.
YAPC::Europe::2018 — Hmmm, need to talk to work about sending me
there or to Mojoconf.
| [reply] |
|
|
I tried it once way back when I first got the option of a portrait-mode capable monitor. It lasted about a week, before I put it back to landscape-mode and never switched again.
Human vision isn't designed for scanning vertically. If I turn my widescreen monitor on its side, if the top is in focus, the bottom isn't and vice versa, and despite a claimed 179° reading angle OLED, when one end is properly visible, the other end looks xray like. And it gives you neck ache.
With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
In the absence of evidence, opinion is indistinguishable from prejudice.
Suck that fhit
| [reply] |
|
|
Human vision isn't designed for scanning vertically
Must be why textbooks, PDFs, magazines, newspapers, mass market paperbacks, and just about all other printed materials are published in landscape mode. As to a possible alternative response regarding human vision and its inherit scanning–
I bet -- in fact I'll pretty much guarantee -- that you cannot cite one authoritative reference for that piece of pseudo-science
As to the question from Ea. I do exactly the same thing you do; one monitor in landscape (image editing, email, etc), one in portrait (code, text oriented Internet browsing, etc). I know a lot of hackers who use portrait mode.
| [reply] |
|
|
|
|
| [reply] |
Re: To <=80 char code line length or not
by karlgoethebier (Abbot) on Jun 09, 2018 at 18:13 UTC
|
| [reply]
[d/l] |
