8 ms·

Is the first chapter explaining why all lines must be less than 80 characters in width and all parameters and conditional statements must be automatically forma

Is the first chapter explaining why all lines must be less than 80 characters in width and all parameters and conditional statements must be automatically formatted in the most compact way possible - damn readability.

Rebelgecko 4y ago
The width limit is per language- some are longer than 80. And some languages, believe it or not, don't even have readability
- google234123 4y ago
  Sorry, i didn’t mean to use that word to mean that. Was just talking about how it’s easier to read parameters and long conditional statements that are split over separate lines.
- jppittma 4y ago
  No languages have readability on GoB. You don’t know what you’ve got until it’s gone.
maskedinvader 4y ago
do we really have to limit 80 chars now? don't we all have bigger monitors and wider screens to accommodate 120 perhaps?
- dmitriid 4y ago
  On a wider screen you will probably have several code windows/panes side by side. So, back to 80 characters :)
  - nickjj 4y ago
    Yep. If you run 2560x1440 at its native resolution you can fit (4) side by side code windows at 80 characters with a very readable font size. Having 120 character lines only lets you have 2 (3 will cut off the last one by a decent amount). Being able to comfortably open 4 files side by side is like having access to a completely new world compared to 2. You can often fit the entire context of what you're working on in one visible space. I use 80 characters for mainly this reason and it's also no extra time spent when using languages like Python because Black will auto-format it for you, it comes down to running 1 command and letting the machine do all of the work.
- helge9210 4y ago
  With 80 chars you could fit three windows with code side by side on standard screen or four on ultra wide.
- LudwigNagasena 4y ago
  Don’t we all have IDEs that enumerate lines and allow wrapping?
  - okamiueru 4y ago
    Not sure what you mean. Soft wrapping?
- omegalulw 4y ago
  Other than the reasons already posted, I find it much easier to read code with 80 char line limits vs longer. For me it's like the benefit of reading an article in columnar format - going down vertically just feels more comfortable.
- ignoramous 4y ago
  While it might be true that 120 chars are ideal for screens [0], the consensus is an optimal line length is roughly 50 to 75 chars. [1] [0] https://www.viget.com/articles/the-line-length-misconception/ https://www.viget.com/articles/the-line-length-misconception... [1] http://webtypography.net/2.1.2 http://webtypography.net/2.1.2
  - kozd 4y ago
    That seems to apply for blocks of text. I don't know that the same would hold true for code.
    - shakezula 4y ago
      What is code if not blocks of text
      - tpush 4y ago
        A tree of nodes.
        shakezula 4y ago
        And we model sentences the same way
      - cjg 4y ago
        Often significantly more indented.
      - YokoZar 4y ago
        Sentences feel different from lines of code. "One statement doing one thing per line of code" seems a reasonable idea but "one sentence per line of text" seems a bit absurd.
  - kitsune_ 4y ago
    Yeah but line formatting usually includes white space indentation in the calculation of the line length, I don't know whether you can 1:1 translate findings from normal text paragraphs like that. With linted code the actual relevant length might only be 20 characters, maybe we need some smarter linters.
- corford 4y ago
  Even Linus seems comfortable with 100 these days: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=bdc48fa11e46f867ea4d75fa59ee87a7f48be144 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin... On my team we've settled for either 100 or 120 depending on language.
- nicogg88 4y ago
  When you take into account IDE stuff like file tree on the left, plugins on the right, or the split view when looking at a file diff, more than 80 char is too much even on a large monitor in my opinion.
- BeetleB 4y ago
  I almost always have multiple files open side by side. Lines longer than 100 characters start wrapping which really hurts readability.
whatever1 4y ago
Why is this a thing in languages that are not Fortran 77? Why not a 1000 character long line? If I want the editor to overflow it below or show me a scrollbar should be my choice.
- nine_k 4y ago
  Diffing an excessively long line is uncomfortable in most tools. A crash dump mentioning the 1000-character line leaves you thinking where in that line the error has happened. The actual limit should be the complexity of one lihe, something like the number of AST nodes in it. But our tools which go back all the way to mechanical teletypes and punched cards are firmly line-oriented. This allows them to be language-agnostic.
  - thfuran 4y ago
    I think it's reasonable to have restrictions on both. Regardless of complexity, long lines make it hard to view side by side diffs on your screen.
- dudeman13 4y ago
  >Why not a 1000 character long line? I work in a codebase where a previous dude constantly did this. I do not find those lines amusing. Whenever I'm un-fucking his stuff one of the first things to do is expand his infinite lines into usually 5-50 lines because visualizing and reasoning about 50 lines of code crammed into one requires someone who is totally a way, way better programmer than me. I don't need to git blame to know when the code was written by that guy.
- compiler-guy 4y ago
  In a personal project that makes a lot of sense (and in a personal project you have your choice), but once you are in a corporate or open source project of more than just a couple of people, code is read far more often than it is written, and by many more people than the original author. In those circumstances, it makes sense to optimize for readability to everyone rather than the author’s personal preferences. One can easily argue that Google’s style isn’t optimal, but it’s harder to argue that a personal preferences free for all is optimal.
iliketrains 4y ago
Having worked at Google for many years, 80 char line limit was easily the biggest frustration with coding. Because of that, I was forced to write less readable code, shorten variable and function names, omit some comments, fight with formatter and linter, spend extra time aligning things, etc. For example, Python requires extra effort to brake lines, often adding extra parentheses or doing other unnecessary tricks. Lambda does not fit on the rest of the line? Too bad, define an extra function, because liner won't let you submit a lambda that spans more than one line... Now, I am so happy with 120 char limit while still being able to fit two columns on one screen.
- foota 4y ago
  Line splitting in python is miserable, all the other languages are much easier for it.
- bjackman 4y ago
  FWIW, a counterpoint: I work in C++ (80) and Go (no line length limit) at Google and I barely even think about it. I just write code however feels natural and then run 'hg fix' before sending for review. I would definitely not impose 80 if it were my choice but it really doesn't bother me when clang-format is set up as nicely as it is. Probably Python should switch to the Go model, since auto-splitting python lines sounds tricky.
  - bpicolo 4y ago
    Black’s model for Python is great. It has a default limit of 88 but will go over that up to 10% if the formatting makes more sense that way.
- bob1029 4y ago
  What is with these draconian rules of having any limit at all? There are tons of edge cases where allowing a 100k line of text would totally make sense to most developers. Are the tools at Google and elsewhere unable to diff code if a line exceeds some arbitrary width?
  - 4y ago
spockz 4y ago
I think we need some contextual line width limits. When splitting a function/method definition over multiple lines, I like to align the parameters. Now if there is a short line limit this will force us to left align the parameters instead. This has the consequences that there is less visual, spatial, distinction between method definition and their code, resulting in a big hodgepodge of characters. If we have contextual limits, we can make method headers arbitrarily long while keeping the body within a tight limit. Or allow a longer line when defining a lambda in python as another comment laments.
- 4ad 4y ago
  > When splitting a function/method definition over multiple lines, I like to align the parameters. Please don't do this. It's horrible for us who use proportional fonts. In fact I would go as far as arguing that "artificial" line breaks are always bad. They aren't really more readable, quite the opposite usually, and most importantly they break diff. I like short lines, and it's a good ideal to strive for. 98.5% of my code fits in 80 columns, but if I need a longer line, don't artificially make it worse in the pursue of some arbitrary rule.
unicornmama 4y ago
This style was written for C++ developers who work author on terminals. It shouldn’t be taken seriously outside that context.
shric 4y ago
The nice thing about books about how Google does X (SRE, SWE, etc.) is you can adopt the good/relevant parts however you see fit and ignore the stuff that either only applies to Google scale or makes no sense.

Rebelgecko 4y ago

The width limit is per language- some are longer than 80. And some languages, believe it or not, don't even have readability

google234123 4y ago
Sorry, i didn’t mean to use that word to mean that. Was just talking about how it’s easier to read parameters and long conditional statements that are split over separate lines.
jppittma 4y ago
No languages have readability on GoB. You don’t know what you’ve got until it’s gone.

maskedinvader 4y ago

do we really have to limit 80 chars now? don't we all have bigger monitors and wider screens to accommodate 120 perhaps?

dmitriid 4y ago
On a wider screen you will probably have several code windows/panes side by side. So, back to 80 characters :)
- nickjj 4y ago
  Yep. If you run 2560x1440 at its native resolution you can fit (4) side by side code windows at 80 characters with a very readable font size. Having 120 character lines only lets you have 2 (3 will cut off the last one by a decent amount). Being able to comfortably open 4 files side by side is like having access to a completely new world compared to 2. You can often fit the entire context of what you're working on in one visible space. I use 80 characters for mainly this reason and it's also no extra time spent when using languages like Python because Black will auto-format it for you, it comes down to running 1 command and letting the machine do all of the work.
helge9210 4y ago
With 80 chars you could fit three windows with code side by side on standard screen or four on ultra wide.
LudwigNagasena 4y ago
Don’t we all have IDEs that enumerate lines and allow wrapping?
- okamiueru 4y ago
  Not sure what you mean. Soft wrapping?
omegalulw 4y ago
Other than the reasons already posted, I find it much easier to read code with 80 char line limits vs longer. For me it's like the benefit of reading an article in columnar format - going down vertically just feels more comfortable.
ignoramous 4y ago
While it might be true that 120 chars are ideal for screens [0], the consensus is an optimal line length is roughly 50 to 75 chars. [1] [0] https://www.viget.com/articles/the-line-length-misconception/ https://www.viget.com/articles/the-line-length-misconception... [1] http://webtypography.net/2.1.2 http://webtypography.net/2.1.2
- kozd 4y ago
  That seems to apply for blocks of text. I don't know that the same would hold true for code.
  - shakezula 4y ago
    What is code if not blocks of text
    - tpush 4y ago
      A tree of nodes.
      - shakezula 4y ago
        And we model sentences the same way
    - cjg 4y ago
      Often significantly more indented.
    - YokoZar 4y ago
      Sentences feel different from lines of code. "One statement doing one thing per line of code" seems a reasonable idea but "one sentence per line of text" seems a bit absurd.
- kitsune_ 4y ago
  Yeah but line formatting usually includes white space indentation in the calculation of the line length, I don't know whether you can 1:1 translate findings from normal text paragraphs like that. With linted code the actual relevant length might only be 20 characters, maybe we need some smarter linters.
corford 4y ago
Even Linus seems comfortable with 100 these days: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=bdc48fa11e46f867ea4d75fa59ee87a7f48be144 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin... On my team we've settled for either 100 or 120 depending on language.
nicogg88 4y ago
When you take into account IDE stuff like file tree on the left, plugins on the right, or the split view when looking at a file diff, more than 80 char is too much even on a large monitor in my opinion.
BeetleB 4y ago
I almost always have multiple files open side by side. Lines longer than 100 characters start wrapping which really hurts readability.

whatever1 4y ago

Why is this a thing in languages that are not Fortran 77? Why not a 1000 character long line? If I want the editor to overflow it below or show me a scrollbar should be my choice.

nine_k 4y ago
Diffing an excessively long line is uncomfortable in most tools. A crash dump mentioning the 1000-character line leaves you thinking where in that line the error has happened. The actual limit should be the complexity of one lihe, something like the number of AST nodes in it. But our tools which go back all the way to mechanical teletypes and punched cards are firmly line-oriented. This allows them to be language-agnostic.
- thfuran 4y ago
  I think it's reasonable to have restrictions on both. Regardless of complexity, long lines make it hard to view side by side diffs on your screen.
dudeman13 4y ago
>Why not a 1000 character long line? I work in a codebase where a previous dude constantly did this. I do not find those lines amusing. Whenever I'm un-fucking his stuff one of the first things to do is expand his infinite lines into usually 5-50 lines because visualizing and reasoning about 50 lines of code crammed into one requires someone who is totally a way, way better programmer than me. I don't need to git blame to know when the code was written by that guy.
compiler-guy 4y ago
In a personal project that makes a lot of sense (and in a personal project you have your choice), but once you are in a corporate or open source project of more than just a couple of people, code is read far more often than it is written, and by many more people than the original author. In those circumstances, it makes sense to optimize for readability to everyone rather than the author’s personal preferences. One can easily argue that Google’s style isn’t optimal, but it’s harder to argue that a personal preferences free for all is optimal.

iliketrains 4y ago

Having worked at Google for many years, 80 char line limit was easily the biggest frustration with coding. Because of that, I was forced to write less readable code, shorten variable and function names, omit some comments, fight with formatter and linter, spend extra time aligning things, etc. For example, Python requires extra effort to brake lines, often adding extra parentheses or doing other unnecessary tricks. Lambda does not fit on the rest of the line? Too bad, define an extra function, because liner won't let you submit a lambda that spans more than one line... Now, I am so happy with 120 char limit while still being able to fit two columns on one screen.

foota 4y ago
Line splitting in python is miserable, all the other languages are much easier for it.
bjackman 4y ago
FWIW, a counterpoint: I work in C++ (80) and Go (no line length limit) at Google and I barely even think about it. I just write code however feels natural and then run 'hg fix' before sending for review. I would definitely not impose 80 if it were my choice but it really doesn't bother me when clang-format is set up as nicely as it is. Probably Python should switch to the Go model, since auto-splitting python lines sounds tricky.
- bpicolo 4y ago
  Black’s model for Python is great. It has a default limit of 88 but will go over that up to 10% if the formatting makes more sense that way.
bob1029 4y ago
What is with these draconian rules of having any limit at all? There are tons of edge cases where allowing a 100k line of text would totally make sense to most developers. Are the tools at Google and elsewhere unable to diff code if a line exceeds some arbitrary width?
- 4y ago

spockz 4y ago

I think we need some contextual line width limits. When splitting a function/method definition over multiple lines, I like to align the parameters. Now if there is a short line limit this will force us to left align the parameters instead. This has the consequences that there is less visual, spatial, distinction between method definition and their code, resulting in a big hodgepodge of characters. If we have contextual limits, we can make method headers arbitrarily long while keeping the body within a tight limit. Or allow a longer line when defining a lambda in python as another comment laments.

4ad 4y ago
> When splitting a function/method definition over multiple lines, I like to align the parameters. Please don't do this. It's horrible for us who use proportional fonts. In fact I would go as far as arguing that "artificial" line breaks are always bad. They aren't really more readable, quite the opposite usually, and most importantly they break diff. I like short lines, and it's a good ideal to strive for. 98.5% of my code fits in 80 columns, but if I need a longer line, don't artificially make it worse in the pursue of some arbitrary rule.

unicornmama 4y ago

This style was written for C++ developers who work author on terminals. It shouldn’t be taken seriously outside that context.

shric 4y ago

The nice thing about books about how Google does X (SRE, SWE, etc.) is you can adopt the good/relevant parts however you see fit and ignore the stuff that either only applies to Google scale or makes no sense.