80 column line limits

Please compose all posts in Emacs.

Moderators: phlip, Moderators General, Prelates

EvanED
Posts: 4330
Joined: Mon Aug 07, 2006 6:28 am UTC
Location: Madison, WI
Contact:

80 column line limits

Postby EvanED » Sat Sep 21, 2013 5:56 am UTC

[The Python thread in the coding forum started devolving into a discussion about 80 character line limits, and after realizing I wrote a long post about that I decided it's better here.]

Jplus wrote:@PM 2Ring: Thanks. I understand the reasoning, but I disagree about me needing to adjust because somebody else might have chosen to use a poorly designed editor. Editors are tools, not audience, and if they cause problems they should be replaced.
How do you think 80 was picked?

It doesn't have any "real" basis to it, so it's just a matter of that's in the general right ballpark. But so is 79, and if you can improve the experience for people using editors that insert the continuation characters while not appreciably affecting anyone else, why not?

And besides, that ignores the possibility that someone actually wants the line continuation characters (presumably in other contexts, but still).

@EvanED: I like to align lines too, but I think you just shouldn't allow them to become longer than 80 characters. 120 characters might not take more scrolling but it does take more head-turning and eye-straining.
Not appreciably more IMO, especially if a lot of the reason that the lines are >80 chars is because of indentation, because you don't realistically have to scan over that. And of course if you start wrapping, you'll take more vertical space, and that's a place where you actually might have to scroll.

If you can't align within 80 columns, you're either using too long names (there's always a solution for that) or trying to show too much information on a single line anyway.
Disagree.

For instance, I prefer this:

Code: Select all

        AccessibleStateMap epsilonCloseCached_MohriDemand     (Key start, EpsilonCloseCache & cache) const;
        AccessibleStateMap epsilonCloseCached_MohriAll        (Key start, EpsilonCloseCache & cache) const;
        AccessibleStateMap epsilonCloseCached_FwpdsDemand     (Key start, EpsilonCloseCache & cache) const;
        AccessibleStateMap epsilonCloseCached_FwpdsAllSingles (Key start, EpsilonCloseCache & cache) const;
        AccessibleStateMap epsilonCloseCached_FwpdsAllMulti   (Key start, EpsilonCloseCache & cache) const;

to anything you could do wrapping, and those are fairly long even by my standard (107 characters). You could use shorter names, but apart from abbreviating epsilonClose with eclose (which would be reasonable), you'd either have to IMO grossly neuter the names in general or introduce a typedef that you use just for those lines, which isn't worth it. Or you could wrap, but the way I'd wrap those lines turns 5 lines into 17 lines and makes it much less apparent that there are several different algorithms for the same problem and what the list of those algorithms is.

Here's another:

Code: Select all

    void appendCall(Symbol sym)     { append(Position(sym, Position::CallType)); }
    void appendInternal(Symbol sym) { append(Position(sym, Position::InternalType)); }
    void appendReturn(Symbol sym)   { append(Position(sym, Position::ReturnType)); }

At 84 characters only barely over the limit, but over nevertheless.

Granted, those are the examples that I feel most strongly about, but there are a number of others I passed up including here because I think a reasonable argument could be made that you could re-write or wrap to under 80 characters easily enough even if I think it would decrease readability.

I agree that one could make an exception for a large 2D array, though. Usually you don't really want to read that so it doesn't matter and it saves vertical space.

Oh there I think it's not even questionable. I have a few test files that basically contain tables of expected results, a la

Code: Select all

static bool expected_answers[][num_words] = {
    /*                     empty    bal    bal0    left   left0    right  right0   full   full0 */
    /* empty          */ { false,   false, false,  false, false,   false, false,   false, false },
    /* balanced only  */ { true,    true,  true,   false, false,   false, false,   false, false },
    /* strictly left  */ { false,   false, false,  true,  true,    false, false,   false, false },
    /* maybe left     */ { true,    true,  true,   true,  true,    false, false,   false, false },
    /* strictly right */ { false,   false, false,  false, false,   true,  true,    false, false },
    /* maybe right    */ { true,    true,  true,   false, false,   true,  true,    false, false },
    /* maybe fully    */ { true,    true,  true,   true,  true,    true,  true,    true,  true  }
};

and wrapping that would just utterly destroy it.


P.S., re
Jplus wrote:

Code: Select all

NamespaceName::ReturnTypeName Classname::Functionname   (
                    ParameterType* ParameterOne,
                    SecondParameterType* ParameterTwo   ) {

Oh god I hate that indentation. :-) But there's a good way to do it that doesn't go above 80 chars (assuming there aren't nearby functions you want to align with):

Code: Select all

NamespaceName::ReturnTypeName
Classname::Functionname(ParameterType* ParameterOne,
                        SecondParameterType* ParameterTwo)
{ ... }
(Or you could put the first parameter on a new line and indent the second less, but I think I don't like that style as much.)

Actually now that I think about it more, I think it's less the indentation and more the fact that a qualified return type (i.e. contains ::) and the function name appear on the same line -- IMO this can make it hard to find the boundary between return type and class/function name, especially if either the return type name or class name is a template. I like to see any qualified return type on its own line for that reason alone (assuming you're not doing an alignment thing like my examples above).

dii
Posts: 164
Joined: Fri Feb 22, 2013 2:42 am UTC
Location: 60.17°N 24.94°E

Re: 80 column line limits

Postby dii » Sat Sep 21, 2013 12:37 pm UTC

EvanED wrote:How do you think 80 was picked?


Historical reasons. The most common text modes on PC graphics adapters were 80x25, 80x50, 80x60 etc. - almost all were 80 characters wide. 80 characters was a de-facto "screen width" back in the day.

User avatar
ahammel
My Little Cabbage
Posts: 2135
Joined: Mon Jan 30, 2012 12:46 am UTC
Location: Vancouver BC
Contact:

Re: 80 column line limits

Postby ahammel » Sat Sep 21, 2013 3:46 pm UTC

I think the advantages of insisting on a hard limit of 80 columns in Python are:

1) That's about the widest I can get on my personal laptop with two windows side-to-side and readable font sizes.
2) Combined with the insistence on 4-space tabs, it's a good way to let novices know that they're doing something wrong, probably nesting loops way too deeply. Whenever I open up a Python file and see wrapping, I know I'm in for some pain.

But really, 1) is the most important. We should all really adopt whatever conventions are most convenient for me personally.
He/Him/His/Alex
God damn these electric sex pants!

User avatar
Jplus
Posts: 1710
Joined: Wed Apr 21, 2010 12:29 pm UTC
Location: Netherlands

Re: 80 column line limits

Postby Jplus » Sat Sep 21, 2013 4:35 pm UTC

EvanED wrote:[The Python thread in the coding forum started devolving into a discussion about 80 character line limits, and after realizing I wrote a long post about that I decided it's better here.]

How about splicing all line limit posts from that thread to here?

EvanED wrote:
Jplus wrote:@PM 2Ring: Thanks. I understand the reasoning, but I disagree about me needing to adjust because somebody else might have chosen to use a poorly designed editor. Editors are tools, not audience, and if they cause problems they should be replaced.
How do you think 80 was picked?

It doesn't have any "real" basis to it, so it's just a matter of that's in the general right ballpark.
Well as far as I understood the exact number was originally based on screen width (ninja'd by dii). Of course the number 80 itself is arbitrary, but it is right in the middle of that ballpark and that ballpark is based on readability, not screen width. Text, which IMO includes source code, becomes less readable when the column width goes beyond 70 printing characters. This is the reason why novels tend to have small formats, why newspapers and magazines put their text in multiple columns, why LaTeX documents leave such wide side margins by default and why it's so damn annoying when a web page full of text wraps to the entire window width. It's a good idea to limit source code width to something close to 70 printing characters for exactly the same reason.

Besides, 80 is much better than 79 because it is a multiple of 4 and 8.
EvanED wrote:But so is 79, and if you can improve the experience for people using editors that insert the continuation characters while not appreciably affecting anyone else, why not?

And besides, that ignores the possibility that someone actually wants the line continuation characters (presumably in other contexts, but still).

@EvanED: I like to align lines too, but I think you just shouldn't allow them to become longer than 80 characters. 120 characters might not take more scrolling but it does take more head-turning and eye-straining.
Not appreciably more IMO, especially if a lot of the reason that the lines are >80 chars is because of indentation, because you don't realistically have to scan over that. And of course if you start wrapping, you'll take more vertical space, and that's a place where you actually might have to scroll.
Sure, you could exclude the indentation from the line limit, but then you create a text column that rocks back and forth horizontally. That's nearly as annoying to read as a "normal" very broad column. Also, as Alex mentioned, if indentation is eating away a lot of your line width you have a reason to consider whether you should be factoring out some things into new functions.
As for vertical scrolling: you have to do that anyway. Any time you read something substantial you have to scroll vertically. People are used to that and nobody seems to suffer from it.

EvanED wrote:
If you can't align within 80 columns, you're either using too long names (there's always a solution for that) or trying to show too much information on a single line anyway.
Disagree.

For instance, I prefer this:

Code: Select all

        AccessibleStateMap epsilonCloseCached_MohriDemand     (Key start, EpsilonCloseCache & cache) const;
        AccessibleStateMap epsilonCloseCached_MohriAll        (Key start, EpsilonCloseCache & cache) const;
        AccessibleStateMap epsilonCloseCached_FwpdsDemand     (Key start, EpsilonCloseCache & cache) const;
        AccessibleStateMap epsilonCloseCached_FwpdsAllSingles (Key start, EpsilonCloseCache & cache) const;
        AccessibleStateMap epsilonCloseCached_FwpdsAllMulti   (Key start, EpsilonCloseCache & cache) const;

to anything you could do wrapping, and those are fairly long even by my standard (107 characters). You could use shorter names, but apart from abbreviating epsilonClose with eclose (which would be reasonable), you'd either have to IMO grossly neuter the names in general or introduce a typedef that you use just for those lines, which isn't worth it. Or you could wrap, but the way I'd wrap those lines turns 5 lines into 17 lines and makes it much less apparent that there are several different algorithms for the same problem and what the list of those algorithms is.
Typedefs would be totally appropriate here, especially since your class almost certainly has more members than just these 5 functions and the AccessibleStateMap and EpsilonCloseCache types probably appear in more places. Typedefs can also play a double role as associated types à la typetraits.

Not wrapping this would add the problem that the const qualifier falls off if somebody uses a window narrower than 106 characters. Like the default codeblock width on these forums.

EvanED wrote:Here's another:

Code: Select all

    void appendCall(Symbol sym)     { append(Position(sym, Position::CallType)); }
    void appendInternal(Symbol sym) { append(Position(sym, Position::InternalType)); }
    void appendReturn(Symbol sym)   { append(Position(sym, Position::ReturnType)); }

At 84 characters only barely over the limit, but over nevertheless.
I find this an edge case. Personally I would just put the function bodies on separate indented lines, IMO that would still show the pattern clearly enough especially if the closing accolades add vertical spacing. But at 84 characters I'm not really offended if you leave it at one line either.

Or, if feasible, do this:

Code: Select all

    void append(Symbol sym, Position::TypeType type) {
        append(Position(sym, type));
    }

That shows the pattern even more clearly.

EvanED wrote:Granted, those are the examples that I feel most strongly about, but there are a number of others I passed up including here because I think a reasonable argument could be made that you could re-write or wrap to under 80 characters easily enough even if I think it would decrease readability.

[...]

P.S., re
Jplus wrote:

Code: Select all

NamespaceName::ReturnTypeName Classname::Functionname   (
                    ParameterType* ParameterOne,
                    SecondParameterType* ParameterTwo   ) {

Oh god I hate that indentation. :-) But there's a good way to do it that doesn't go above 80 chars (assuming there aren't nearby functions you want to align with):

Code: Select all

NamespaceName::ReturnTypeName
Classname::Functionname(ParameterType* ParameterOne,
                        SecondParameterType* ParameterTwo)
{ ... }
(Or you could put the first parameter on a new line and indent the second less, but I think I don't like that style as much.)

Actually now that I think about it more, I think it's less the indentation and more the fact that a qualified return type (i.e. contains ::) and the function name appear on the same line -- IMO this can make it hard to find the boundary between return type and class/function name, especially if either the return type name or class name is a template. I like to see any qualified return type on its own line for that reason alone (assuming you're not doing an alignment thing like my examples above).
Now that you remind me of it, I totally agree with this.
"There are only two hard problems in computer science: cache coherence, naming things, and off-by-one errors." (Phil Karlton and Leon Bambrick)

coding and xkcd combined

(Julian/Julian's)

User avatar
hotaru
Posts: 1040
Joined: Fri Apr 13, 2007 6:54 pm UTC

Re: 80 column line limits

Postby hotaru » Sat Sep 21, 2013 6:25 pm UTC

Jplus wrote:Besides, 80 is much better than 79 because it is a multiple of 4 and 8.

isn't every number that's a multiple of 8 also a multiple of 4?

Code: Select all

factorial product enumFromTo 1
isPrime n 
factorial (1) `mod== 1

User avatar
Jplus
Posts: 1710
Joined: Wed Apr 21, 2010 12:29 pm UTC
Location: Netherlands

Re: 80 column line limits

Postby Jplus » Sat Sep 21, 2013 8:32 pm UTC

Hm, come to think of it...
"There are only two hard problems in computer science: cache coherence, naming things, and off-by-one errors." (Phil Karlton and Leon Bambrick)

coding and xkcd combined

(Julian/Julian's)

dii
Posts: 164
Joined: Fri Feb 22, 2013 2:42 am UTC
Location: 60.17°N 24.94°E

Re: 80 column line limits

Postby dii » Sun Sep 22, 2013 9:13 am UTC

hotaru wrote:
Jplus wrote:Besides, 80 is much better than 79 because it is a multiple of 4 and 8.

isn't every number that's a multiple of 8 also a multiple of 4?


Prove it.

User avatar
ahammel
My Little Cabbage
Posts: 2135
Joined: Mon Jan 30, 2012 12:46 am UTC
Location: Vancouver BC
Contact:

Re: 80 column line limits

Postby ahammel » Sun Sep 22, 2013 3:59 pm UTC

Point of interest: when typesetting books and suchlike, lines anywhere between 45 and 75 characters long are considered satisfactorily readable, and an average of 66 characters per line is meant to be ideal.
He/Him/His/Alex
God damn these electric sex pants!

User avatar
Xeio
Friends, Faidites, Countrymen
Posts: 5092
Joined: Wed Jul 25, 2007 11:12 am UTC
Location: C:\Users\Xeio\
Contact:

Re: 80 column line limits

Postby Xeio » Fri Sep 27, 2013 3:20 pm UTC

In visual studio I tend towards whatever-width-I-feel-like. Most devs at work run VS full screen, potentially with the code files themselves full screen. Screen width isn't generally an issue. I can see >170 characters right now, and I easily have lines that go over 80 because that's an arbitrarily tiny count.

I think our style guide is technically to never to break lines for length (the Resharper settings will auto-format like that anyway) but I usually override for readability. Function definitions rarely get broken onto multiple lines, but large array definitions often do so all values are visible.

User avatar
sparkyb
Posts: 1091
Joined: Thu Sep 06, 2007 7:30 pm UTC
Location: Camberville proper!
Contact:

Re: 80 column line limits

Postby sparkyb » Mon Oct 14, 2013 11:54 pm UTC

Xeio wrote:In visual studio I tend towards whatever-width-I-feel-like. Most devs at work run VS full screen, potentially with the code files themselves full screen. Screen width isn't generally an issue. I can see >170 characters right now


I agree with you, but at my office a number of devs with VS full screen on a nice widescreen monitor have split it into 2 or sometimes even 3 code files side-by-side reducing the width of a single file back down towards the 80 column range. I, myself, don't think seeing multiple files at once outweighs not arbitrarily wrapping single statements. However, since we've switched to doing mandatory code reviews on every check-in, it is quite annoying (and embarrassing) to have to scroll horizontally to show a coworker the end of a long line in a side-by-side diff.

User avatar
Xenomortis
Not actually a special flower.
Posts: 1420
Joined: Thu Oct 11, 2012 8:47 am UTC

Re: 80 column line limits

Postby Xenomortis » Wed Oct 16, 2013 8:07 am UTC

Get more monitors?
Image

Lonnie Riskle
Posts: 0
Joined: Tue Dec 03, 2013 10:49 am UTC

Re: 80 column line limits

Postby Lonnie Riskle » Tue Dec 03, 2013 11:25 am UTC

I suspect the 80 character line is just a hang-over from the old days, and screen sizes aren't the cause, they're just another symptom.

Sorry, guys, history lecture coming up. :(

In the Very Old Days, programs and data were put into computers by punched card, and each card had 80 columns on it. This meant that a line of code had a physical maximum of 80 characters. Data too; I used – as late as 1986 – to write routines to chop 'long' data lines down to 80 characters so we could upload them to the company mainframe, and then reassemble them to their true length.

When teletypes were used to interface with the computer you needed 80 columns to display each line correctly. And early Visual Display Units[VDUs] (screens) needed to do the same. By this time output was produced on 'line printers' that generally had 132 columns, so quite early on VDUs started to have a 132-column mode, to let you see your output properly on screen.

It seems that the 80/132 limits live on in people's heads.

(I suspect that the actual values (80 & 132) came about because it was what IBM decided to do.)

User avatar
chridd
Has a vermicelli title
Posts: 814
Joined: Tue Aug 19, 2008 10:07 am UTC
Location: ...Earth, I guess?
Contact:

Re: 80 column line limits

Postby chridd » Wed Dec 04, 2013 6:58 am UTC

Clearly we need editors with better word wrapping (when displaying, not as
actual newlines in the file). (Are there some already?) We can type whole
paragraphs of English text (or other natural languages) without explicitly
inserting line breaks after a certain number of characters; with all the syntax-
aware features text editors already have, it seems like they should be able to
wrap lines at the right places and with the right indentation.
~ chri d. d. /tʃɹɪ.di.di/ (Phonotactics, schmphonotactics) · she(?)(?(?)(?))(?(?(?))(?))(?) · Forum game scores
mittfh wrote:I wish this post was very quotable...
flicky1991 wrote:In both cases the quote is "I'm being quoted too much!"

User avatar
Jplus
Posts: 1710
Joined: Wed Apr 21, 2010 12:29 pm UTC
Location: Netherlands

Re: 80 column line limits

Postby Jplus » Wed Dec 04, 2013 9:06 am UTC

Lonnie Riskle wrote:I suspect the 80 character line is just a hang-over from the old days, and screen sizes aren't the cause, they're just another symptom.

Sorry, guys, history lecture coming up. :(

In the Very Old Days, programs and data were put into computers by punched card, and each card had 80 columns on it. This meant that a line of code had a physical maximum of 80 characters.

Ok, so the number 80 seems to date back to punchcards. That's interesting. Still, I think my readability argument remains.

@chridd: the text editors I use, i.e. Textwrangler and Textastic, already do that.
"There are only two hard problems in computer science: cache coherence, naming things, and off-by-one errors." (Phil Karlton and Leon Bambrick)

coding and xkcd combined

(Julian/Julian's)

User avatar
Thesh
Made to Fuck Dinosaurs
Posts: 5975
Joined: Tue Jan 12, 2010 1:55 am UTC
Location: Colorado

Re: 80 column line limits

Postby Thesh » Mon Dec 23, 2013 5:19 am UTC

You know, when I have multiple high resolution monitors, I don't really care about column limits, or if I did I would limit it to something like 96 or 120 columns, just because it seemed like 80 was too little. But on the last thing I did on my laptop without a second monitor, using vim, I find that 80 characters is pretty much perfect for two windows with a vertical split.
Summum ius, summa iniuria.

lgw
Posts: 435
Joined: Mon Apr 12, 2010 10:52 pm UTC

Re: 80 column line limits

Postby lgw » Mon Dec 30, 2013 9:56 pm UTC

I've worked in a language that had to fit in 80 columns because punchcards. Fuck punchcards. The "80-column mind" is not a good thing: my greenbar paper is 132 columns wide, and I should get to use all of my page when printing code for review before submitting it to the compile queue overnight.

More seriously, an 80-column limit stopped making sense somewhere between 30 and 40 years ago. Do we have to re-invent every wheel every generation in this industry, or can we just once realize that some prior work exists? OK, /rant off, back to re-inventing the mainframe and calling it "cloud".
"In no set of physics laws do you get two cats." - doogly


Return to “Religious Wars”

Who is online

Users browsing this forum: No registered users and 5 guests