13 ms·

One little quibble in an excellent talk: 80 cols exists for a reason. It means people don't have to lay out their editor and shell to match your code. Your edit

by sago 11y ago

One little quibble in an excellent talk: 80 cols exists for a reason. It means people don't have to lay out their editor and shell to match your code. Your editor can be set to 80 col, your shell can too, and then you can leave it and it should work across languages, code-bases, and libraries. An extra line break here or there is preferable to having to drag windows around to read your code. At 80 cols I can get three editor windows on screen, allowing me great views of a lot of relevant code for the bit I'm writing, or a shell in place of one editor that I can be running tests on. Once 82 cols is okay, why not 84, or 90, or 100? What about when the middle column needs 84 cols, and I have to drag everything around. That's rude and productivity sapping. I know some people program with one editor maximised and can have 200 character lines if they like, but a specific width as a convention is helpful. And the convention that is already widely used is going to make fewer people have to accommodate you. The 'ish' is useless in that regard.

jakeogh 11y ago
I'm sure you know it's an old design decision that was practical at the time. 100 years from now are we still going to be stuck with 80col's? In your example making the interface smarter could remove the need to manually resize boxes. I like standards, but 80 chars just isnt enough and never was. Is 96 the next reasonable number?
- sago 11y ago
  'Stuck with'? I don't think we're stuck with anything. I think 80 cols is a very practical width. Most lines in code that is well structured and simple are less than 80 cols wide. Lines that require more than that can be broken. I think in 20 years of Python I've only seen a couple of cases where there wasn't an obvious semantic break point, most of the time such breaks are easy to place at logical points. When you have 80 cols you have more code in your window. You can use the resolution to have taller windows and more windows side-by-side. 1920 pixels gives you nicely 3x80 col editors. Which allows you to look at the code, and its tests, and the shell at the same time, for example.
  - jakeogh 11y ago
    "1920 pixels gives you nicely 3x80 col editors" Depending on your font. I use 1920 (-Misc-Fixed-Medium-R-SemiCondensed--13-120-75-75-C-60-ISO10646-1), and I get almost 4x80 col's, 3x96 works nice.
    - sago 11y ago
      Right, I have a pair of 1920s portrait so I can have more drops on my desktop, but on my 17inch MBP, more than 3 drops is too small for my middle-aged eyes. As the commenter above stated, he found considerably less than 1% of his lines required > 80 cols, so rather than go 96 cols and have 17% of my screen real estate wasted, I'll have the extra column of code or documentation or tests, or output, and have to toggle less.
- teddyh 11y ago
  80 columns was chosen because it fits well with documents produced for old-style fixed-with manual mechanichal typewriter paper. (If you look at the old text files, like the oldest RFC’s, they match this style, and early terminals were made by hooking electric typewriters to computers and supplying a very large spool of paper.) I’ve seen 66 characters recommended as a maximum line width as a style guide for typewritten documents. You also want some extra room for extra margins, line numbering, etc. If 66 is taken as a good minimal number, then 64 (2⁶) is too small, so let’s add, say, 16 to 64, giving 80 columns. Paper documents have the form that they do for a reason. You never saw someone writing sideways on a paper (landscape alignment). This is because readability suffers when lines are too long. Even if boxes resized automatically, it’s the line length that’s the problem, not the resizing or scrolling.
rectangletangle 11y ago
I agree that a standard is useful. However, monitors have changed drastically since the 80 column standard was agreed upon. I'm fond of 120, I think it strikes an ideal balance.
- sago 11y ago
  So set up at 120, and then look at someone's code that's used 128 consistently. And then reformat for those few lines that went that long. See the point? You can't standardise based on what you are fond of. That's the point of a standard. When such a large proportion of people, and the standard library, and most shells, use 80, then using 120 will inconvenience them. If you load my 80col code into your 120 col editor, it will not inconvenience you at all, barring an occasional extra line break.
  - rectangletangle 11y ago
    I get that. But a large section of the Python community has standardized on 120, and I'm adding to it in hopes of hitting critical mass.
    - sago 11y ago
      In your average code, what proportion of lines of code are > 80 cols?
      - rectangletangle 11y ago
        >>py34 lns.py total lines: 2099 0.063% over 80 Not many apparently, and a significant portion of them are hard coded URLs/strings in scripts. I guess I stand corrected, 120 isn't that useful... import os from pathlib import Path def walklines(glob='**/*.py'): for filename in Path(os.getcwd()).glob(glob): with open(str(filename)) as file: for line in file.readlines(): yield line if __name__ == '__main__': alllines = [line for line in walklines() if line] totallines = len(alllines) cutoff = 80 total_long_lines = len([line for line in alllines if len(line) > cutoff]) prcnt_long = total_long_lines / totallines print('total lines: {}'.format(totallines)) print('{:.3f}% over {}'.format(prcnt_long, cutoff))
david-given 11y ago
One size doesn't fit all --- if a particular language culture is focused around shell terminals, it'll probably go for 80. If it's focused around IDEs, like Java, it'll probably be about 100. (Go, for some reason, doesn't like splitting lines at all, no matter how wide. I've had code reviewers criticise me splitting lines at 200, which I don't understand at all.)
- rectangletangle 11y ago
  There's a certain point where an expression becomes difficult to read, because it's too long. If you're pushing 100, it likely means you should separate the logic out into a few smaller expressions.
  - andreasvc 11y ago
    When you have a function with a large number of parameters, splitting into expressions does not help, but splitting over multiple lines looks much clearer.
kashif 11y ago
Another reason that 80 cols mattered was because code could be printed properly on an 80 col dot matrix printer - way back then. Today, you can set your editor/ide to wrap it for you and you should - just 80 is such a waste of space on a modern display.
- sago 11y ago
  > 80 is such a waste of space on a modern display. You're assuming you have just one window open, aren't you? There's less wasted space with 80 cols if you have multiple columns (of the same file, or different files). The math is elsewhere in this thread.
Retra 11y ago
My concern with 80 cols is that it is not friendly to dynamic languages that allow nested definitions, or long variable names. if __name__ == '__main__': def this_is_a_function(*args, **kwargs): def this_is_a_helper_function(arg1, arg2=('this line is already indented 39 ' 'chars!')): this_long_variable = ("Don't put an expression here unless you " "want to use useless intermediate variabls.") return this_long variable if var else 'really short here' return 1 And some people want to insist on 8 char indents!
- deleted 11y ago
  [deleted]
- bpicolo 11y ago
  Then use better whitespace rules. Not to mention the helper isn't capturing any closure here so it's not particularly useful inline, and even when they are you can refactor variable capture to new functions. Nested definitions in python are pretty rare, and oft unnecessary if __name__ == '__main__': def this_is_a_function(*args, **kwargs): def this_is_a_helper_function( arg1, arg2='this line is now indented 12 chars!' ): this_long_variable = ( "Don't put an expression here unless you " "want to use useless intermediate variabls." ) return this_long variable if var else 'really short here' return 1
  - deleted 11y ago
    [deleted]
  - JadeNB 11y ago
    Surely the fact that there are two typos in your code, one of them in the name of a variable (`this_long_variable` vs `this_long variable`), indicates that things can go wrong when you abstract out a literal to a variable?
bsder 11y ago
> One little quibble in an excellent talk: 80 cols exists for a reason. Ayup. That reason is teletypewriters (aka ttys). The biggest problem I have with most programmers is naming things well. 80 columns is anathema to good naming. People start using mbl instead of maxExchangeBufferLengthBytes. No, I'm not a Java guy. I spend a LOT of time chewing through embedded C code. I don't even have good autocomplete in most embedded IDE's, and I STILL prefer maxExchangeBufferLengthBytes. Here's why--that name tells me many things at a glance: max--limit of some form, probably should be positive ExchangeBuffer--a buffer and it's functional purpose LengthBytes--a length (so likely unsigned and if I see differently I should pause) in bytes (not items). You would be amazed at the number of bugs this circumvents. That's a huge amount of information conveyed in 30 bytes. But that's almost half of 80 columns. Add in something like 8 column indents and you can't even name things well. And, that still probably doesn't give me enough information. I need to look at that to see if that is constant, and I probably need to see if I can touch that without concurrency considerations. I read code far more often than I type it. I read code after I have forgotten about it far more often than when it is fresh. Naming things to enable me to come back to my code 6 years later, refresh my memory, and not screw up while doing it is the single most important task in my programming. 80 columns is simply not conducive to that.
- sago 11y ago
  Can you give an actual example of some well-written Python code that you can't fit maxExchangeBufferLengthBytes in? It's a bit handwavey otherwise. I'm also a long-names fan, sometimes I go overboard, but in 20 years I've not been able to logically break my line in an obvious place only once or twice.
  - RussianCow 11y ago
    If you add two of those variables and assign the result to another variable, you're already at about 96 characters before considering whitespace. I don't think it's that hard to exceed 80 characters doing very simple things.
    - 11y ago
coldtea 11y ago
>One little quibble in an excellent talk: 80 cols exists for a reason. It means people don't have to lay out their editor and shell to match your code. Your editor can be set to 80 col, your shell can too, and then you can leave it and it should work across languages, code-bases, and libraries. Yeah, that was nice for 80 line terminals in 1986. This is 2015. We have 27" screens. Two of them for most of us. And on our lowly laptops, we have hi-dpi fonts (which makes smaller fonts sizes read great) and widescreens.
- sago 11y ago
  Right, and that means we can have more code on screen, and docs and tests, and shell. Where is the rule that you have to have one window open at a time? That's the real throwback to terminal interfaces. The number of programmers I see manically toggling through their code in one window is crazy. I think this is part of the legacy of some high-profile IDEs that gave you one window at a time. What proportion of your code lines are > 80 cols? Multiply that by the amount of extra width to get the wasted screen estate. I'll take that and put more code/docs/tests/output on my screen at the same time and have to toggle less. The idea that this is about teletype is very amusing, but rather naive.
  - coldtea 11y ago
    >Where is the rule that you have to have one window open at a time? That's the real throwback to terminal interfaces. Even on a widescreen laptop you can have 2 > 100 lines windows side by side. And for multi-monitor setups you can go even wilder. >The number of programmers I see manically toggling through their code in one window is crazy. I think this is part of the legacy of some high-profile IDEs that gave you one window at a time. If you have tons of junk in front of you, you're not focusing on your code as you should be.
    - sago 11y ago
      Right, I can fit 2x100 cols, or 3x80 cols + a project view. So I can see my code, its tests, and either the shell (i.e. test results, ipython, debugger, tail -f logfile) or a web browser for documentation. Is that junk? How many of your lines require that 100 columns, in your average code? Of course, this can just descend into a pissing contest. The point isn't who-has-the-most-windows, but that the logic of 80cols has a practical point, and programmers who continue with the default have reasons that aren't just about teletype or not moving with the times.
dilap 11y ago
Word processors have soft-wrapped since like forever. Recently code-editors have started to learn how. Don't wrap your lines at all; let the editor do that, in realtime, and you can have your windows at whatever width you want.
BurningFrog 11y ago
> 80 cols exists for a reason As far as I can tell, that reason is the IBM 80 column punch card standard launched in 1928: https://en.wikipedia.org/wiki/Punched_card#IBM_80-column_punched_card_formats_and_character_codes https://en.wikipedia.org/wiki/Punched_card#IBM_80-column_pun...
- woofyman 11y ago
  Only the first 72 columns were available for code. The last 8 were reserved for the collation sequence. Which was handy if you dropped your card deck.
__clazz__ 11y ago
When people don't wrap at a reasonable width, IntelliJ's soft wrap settings are the next-best thing: Settings > Editor > General: * check "Use soft wraps in editor" * check "Use original line's indent for wrapped parts" * enter 4 for "Additional shift" * if you open huge files with wide lines, check "Show soft wraps for current line only" to prevent slowness
- masklinn 11y ago
  Are… are you a wizard? I didn't know about this setting, thanks, I'm pretty sure it's going to change my life for the better.
rbanffy 11y ago
> 80 cols exists for a reason I like to joke God made The VT52 with 80 columns because that's how terminals should be. Another I use is that "80 columns should be enough for anyone". Now, seriously, code that's too wide (or too long) is a code smell. You probably should name your variables better, have fewer them in scope or just refactor the code to be more readable. Remember: code is executed by very cheaply and read by very expensive humans. Optimize for the latter.
Too 11y ago
Python frequently gets away with 80 because you don't have 8 characters of wasted indentation for namespace and classes as you do in say C# or Java. But then again it compensates for that by adding underscores_in_every_variable_name. Anyway, for me anything below 100 just encourages violation of the rule or crappy variable naming, you can still have at least 2 files + project explorer open per monitor.

by sago 11y ago

jakeogh 11y ago

I'm sure you know it's an old design decision that was practical at the time. 100 years from now are we still going to be stuck with 80col's? In your example making the interface smarter could remove the need to manually resize boxes. I like standards, but 80 chars just isnt enough and never was. Is 96 the next reasonable number?

sago 11y ago
'Stuck with'? I don't think we're stuck with anything. I think 80 cols is a very practical width. Most lines in code that is well structured and simple are less than 80 cols wide. Lines that require more than that can be broken. I think in 20 years of Python I've only seen a couple of cases where there wasn't an obvious semantic break point, most of the time such breaks are easy to place at logical points. When you have 80 cols you have more code in your window. You can use the resolution to have taller windows and more windows side-by-side. 1920 pixels gives you nicely 3x80 col editors. Which allows you to look at the code, and its tests, and the shell at the same time, for example.
- jakeogh 11y ago
  "1920 pixels gives you nicely 3x80 col editors" Depending on your font. I use 1920 (-Misc-Fixed-Medium-R-SemiCondensed--13-120-75-75-C-60-ISO10646-1), and I get almost 4x80 col's, 3x96 works nice.
  - sago 11y ago
    Right, I have a pair of 1920s portrait so I can have more drops on my desktop, but on my 17inch MBP, more than 3 drops is too small for my middle-aged eyes. As the commenter above stated, he found considerably less than 1% of his lines required > 80 cols, so rather than go 96 cols and have 17% of my screen real estate wasted, I'll have the extra column of code or documentation or tests, or output, and have to toggle less.
teddyh 11y ago
80 columns was chosen because it fits well with documents produced for old-style fixed-with manual mechanichal typewriter paper. (If you look at the old text files, like the oldest RFC’s, they match this style, and early terminals were made by hooking electric typewriters to computers and supplying a very large spool of paper.) I’ve seen 66 characters recommended as a maximum line width as a style guide for typewritten documents. You also want some extra room for extra margins, line numbering, etc. If 66 is taken as a good minimal number, then 64 (2⁶) is too small, so let’s add, say, 16 to 64, giving 80 columns. Paper documents have the form that they do for a reason. You never saw someone writing sideways on a paper (landscape alignment). This is because readability suffers when lines are too long. Even if boxes resized automatically, it’s the line length that’s the problem, not the resizing or scrolling.

rectangletangle 11y ago

I agree that a standard is useful. However, monitors have changed drastically since the 80 column standard was agreed upon. I'm fond of 120, I think it strikes an ideal balance.

sago 11y ago
So set up at 120, and then look at someone's code that's used 128 consistently. And then reformat for those few lines that went that long. See the point? You can't standardise based on what you are fond of. That's the point of a standard. When such a large proportion of people, and the standard library, and most shells, use 80, then using 120 will inconvenience them. If you load my 80col code into your 120 col editor, it will not inconvenience you at all, barring an occasional extra line break.
- rectangletangle 11y ago
  I get that. But a large section of the Python community has standardized on 120, and I'm adding to it in hopes of hitting critical mass.
  - sago 11y ago
    In your average code, what proportion of lines of code are > 80 cols?
    - rectangletangle 11y ago
      >>py34 lns.py total lines: 2099 0.063% over 80 Not many apparently, and a significant portion of them are hard coded URLs/strings in scripts. I guess I stand corrected, 120 isn't that useful... import os from pathlib import Path def walklines(glob='**/*.py'): for filename in Path(os.getcwd()).glob(glob): with open(str(filename)) as file: for line in file.readlines(): yield line if __name__ == '__main__': alllines = [line for line in walklines() if line] totallines = len(alllines) cutoff = 80 total_long_lines = len([line for line in alllines if len(line) > cutoff]) prcnt_long = total_long_lines / totallines print('total lines: {}'.format(totallines)) print('{:.3f}% over {}'.format(prcnt_long, cutoff))

david-given 11y ago

One size doesn't fit all --- if a particular language culture is focused around shell terminals, it'll probably go for 80. If it's focused around IDEs, like Java, it'll probably be about 100. (Go, for some reason, doesn't like splitting lines at all, no matter how wide. I've had code reviewers criticise me splitting lines at 200, which I don't understand at all.)

rectangletangle 11y ago
There's a certain point where an expression becomes difficult to read, because it's too long. If you're pushing 100, it likely means you should separate the logic out into a few smaller expressions.
- andreasvc 11y ago
  When you have a function with a large number of parameters, splitting into expressions does not help, but splitting over multiple lines looks much clearer.

kashif 11y ago

Another reason that 80 cols mattered was because code could be printed properly on an 80 col dot matrix printer - way back then. Today, you can set your editor/ide to wrap it for you and you should - just 80 is such a waste of space on a modern display.

sago 11y ago
> 80 is such a waste of space on a modern display. You're assuming you have just one window open, aren't you? There's less wasted space with 80 cols if you have multiple columns (of the same file, or different files). The math is elsewhere in this thread.

Retra 11y ago

My concern with 80 cols is that it is not friendly to dynamic languages that allow nested definitions, or long variable names. if __name__ == '__main__': def this_is_a_function(*args, **kwargs): def this_is_a_helper_function(arg1, arg2=('this line is already indented 39 ' 'chars!')): this_long_variable = ("Don't put an expression here unless you " "want to use useless intermediate variabls.") return this_long variable if var else 'really short here' return 1 And some people want to insist on 8 char indents!

deleted 11y ago
[deleted]
bpicolo 11y ago
Then use better whitespace rules. Not to mention the helper isn't capturing any closure here so it's not particularly useful inline, and even when they are you can refactor variable capture to new functions. Nested definitions in python are pretty rare, and oft unnecessary if __name__ == '__main__': def this_is_a_function(*args, **kwargs): def this_is_a_helper_function( arg1, arg2='this line is now indented 12 chars!' ): this_long_variable = ( "Don't put an expression here unless you " "want to use useless intermediate variabls." ) return this_long variable if var else 'really short here' return 1
- deleted 11y ago
  [deleted]
- JadeNB 11y ago
  Surely the fact that there are two typos in your code, one of them in the name of a variable (`this_long_variable` vs `this_long variable`), indicates that things can go wrong when you abstract out a literal to a variable?

bsder 11y ago

> One little quibble in an excellent talk: 80 cols exists for a reason. Ayup. That reason is teletypewriters (aka ttys). The biggest problem I have with most programmers is naming things well. 80 columns is anathema to good naming. People start using mbl instead of maxExchangeBufferLengthBytes. No, I'm not a Java guy. I spend a LOT of time chewing through embedded C code. I don't even have good autocomplete in most embedded IDE's, and I STILL prefer maxExchangeBufferLengthBytes. Here's why--that name tells me many things at a glance: max--limit of some form, probably should be positive ExchangeBuffer--a buffer and it's functional purpose LengthBytes--a length (so likely unsigned and if I see differently I should pause) in bytes (not items). You would be amazed at the number of bugs this circumvents. That's a huge amount of information conveyed in 30 bytes. But that's almost half of 80 columns. Add in something like 8 column indents and you can't even name things well. And, that still probably doesn't give me enough information. I need to look at that to see if that is constant, and I probably need to see if I can touch that without concurrency considerations. I read code far more often than I type it. I read code after I have forgotten about it far more often than when it is fresh. Naming things to enable me to come back to my code 6 years later, refresh my memory, and not screw up while doing it is the single most important task in my programming. 80 columns is simply not conducive to that.

sago 11y ago
Can you give an actual example of some well-written Python code that you can't fit maxExchangeBufferLengthBytes in? It's a bit handwavey otherwise. I'm also a long-names fan, sometimes I go overboard, but in 20 years I've not been able to logically break my line in an obvious place only once or twice.
- RussianCow 11y ago
  If you add two of those variables and assign the result to another variable, you're already at about 96 characters before considering whitespace. I don't think it's that hard to exceed 80 characters doing very simple things.
  - 11y ago

coldtea 11y ago

>One little quibble in an excellent talk: 80 cols exists for a reason. It means people don't have to lay out their editor and shell to match your code. Your editor can be set to 80 col, your shell can too, and then you can leave it and it should work across languages, code-bases, and libraries. Yeah, that was nice for 80 line terminals in 1986. This is 2015. We have 27" screens. Two of them for most of us. And on our lowly laptops, we have hi-dpi fonts (which makes smaller fonts sizes read great) and widescreens.

sago 11y ago
Right, and that means we can have more code on screen, and docs and tests, and shell. Where is the rule that you have to have one window open at a time? That's the real throwback to terminal interfaces. The number of programmers I see manically toggling through their code in one window is crazy. I think this is part of the legacy of some high-profile IDEs that gave you one window at a time. What proportion of your code lines are > 80 cols? Multiply that by the amount of extra width to get the wasted screen estate. I'll take that and put more code/docs/tests/output on my screen at the same time and have to toggle less. The idea that this is about teletype is very amusing, but rather naive.
- coldtea 11y ago
  >Where is the rule that you have to have one window open at a time? That's the real throwback to terminal interfaces. Even on a widescreen laptop you can have 2 > 100 lines windows side by side. And for multi-monitor setups you can go even wilder. >The number of programmers I see manically toggling through their code in one window is crazy. I think this is part of the legacy of some high-profile IDEs that gave you one window at a time. If you have tons of junk in front of you, you're not focusing on your code as you should be.
  - sago 11y ago
    Right, I can fit 2x100 cols, or 3x80 cols + a project view. So I can see my code, its tests, and either the shell (i.e. test results, ipython, debugger, tail -f logfile) or a web browser for documentation. Is that junk? How many of your lines require that 100 columns, in your average code? Of course, this can just descend into a pissing contest. The point isn't who-has-the-most-windows, but that the logic of 80cols has a practical point, and programmers who continue with the default have reasons that aren't just about teletype or not moving with the times.

dilap 11y ago

Word processors have soft-wrapped since like forever. Recently code-editors have started to learn how. Don't wrap your lines at all; let the editor do that, in realtime, and you can have your windows at whatever width you want.

BurningFrog 11y ago

> 80 cols exists for a reason As far as I can tell, that reason is the IBM 80 column punch card standard launched in 1928: https://en.wikipedia.org/wiki/Punched_card#IBM_80-column_punched_card_formats_and_character_codes https://en.wikipedia.org/wiki/Punched_card#IBM_80-column_pun...

woofyman 11y ago
Only the first 72 columns were available for code. The last 8 were reserved for the collation sequence. Which was handy if you dropped your card deck.

__clazz__ 11y ago

When people don't wrap at a reasonable width, IntelliJ's soft wrap settings are the next-best thing: Settings > Editor > General: * check "Use soft wraps in editor" * check "Use original line's indent for wrapped parts" * enter 4 for "Additional shift" * if you open huge files with wide lines, check "Show soft wraps for current line only" to prevent slowness

masklinn 11y ago
Are… are you a wizard? I didn't know about this setting, thanks, I'm pretty sure it's going to change my life for the better.

rbanffy 11y ago

> 80 cols exists for a reason I like to joke God made The VT52 with 80 columns because that's how terminals should be. Another I use is that "80 columns should be enough for anyone". Now, seriously, code that's too wide (or too long) is a code smell. You probably should name your variables better, have fewer them in scope or just refactor the code to be more readable. Remember: code is executed by very cheaply and read by very expensive humans. Optimize for the latter.

Too 11y ago

Python frequently gets away with 80 because you don't have 8 characters of wasted indentation for namespace and classes as you do in say C# or Java. But then again it compensates for that by adding underscores_in_every_variable_name. Anyway, for me anything below 100 just encourages violation of the rule or crappy variable naming, you can still have at least 2 files + project explorer open per monitor.