4 ms·

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

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?
- nextlevelwizard 4y ago
  >There are tons of edge cases where allowing a 100k line of text would totally make sense Can you give one?
  - Tepix 4y ago
    An art project!
    - nextlevelwizard 4y ago
      Yeah if you embed a random 100000 character art project as one liner in your code you have bigger problems than 100000 character line in your code.
  - bob1029 4y ago
    Sure. Unit test where you have hundreds of signature specimens which need to be evaluated against graphics processing code. Maintaining a separate list of binary files for each resource was a mess for us. Inline base64 string in each unit test method containing the exact specimen was way more convenient. These lines are long but cause no trouble for IDE responsiveness or our github tooling.
    - the-lazy-guy 4y ago
      I think maintaining a directory of binary files and using it at runtime is a lot better in the long run. Either through a separate build step which embeds them into the test binary. Or via proper env setup where tests actually know how to find the data in the file system. At the very least you can inspect your test data easily without having to extract it from base64-encoded strings. Current approach may be working for your team, but I can totally see why a company which has a dedicated team working on build and testing infra, prefers a slightly more complex approach. It requires one-off investment in tooling which can be payed off very soon given enough people using it.
    - nextlevelwizard 4y ago
eadmund 4y ago
> Python requires extra effort to brake lines, often adding extra parentheses or doing other unnecessary tricks. There are much more compact languages than Python. > Now, I am so happy with 120 char limit while still being able to fit two columns on one screen. The standard width of a terminal is 80 characters; if you are writing 120-character-wide code then your lines will read very poorly on a terminal, or a window sized to a terminal. Note too that to be readable text should not be too wide, which is why newspaper columns are narrower, and why websites normally try to have a fairly narrow text box. It turns out that 80 characters wide is a pretty good readability standard.
- sly010 4y ago
  You are repeating an argument you read somewhere, not actually something you believe. No-one sizes their terminals to 80chars. Heck, I don't even remember the last time I came across one, maybe other than some BIOS over RS232 (i.e. NOT coding). For the 0% of you who code on a dot matrix printer, please enable line wrapping in your editor and let the rest of the world move on. I am not saying lines should be arbitrary long, but a 100-120 _soft_ limit would really not hurt anyone and would help code readability a LOT. p.s. even dot matrix printers support a 100 character mode. EDIT: long lines only reduce readability for prose. Code is inherently easier to parse for the eye because it has a shape. Unless of course if you f--k up that shape with arbitrary line breaks.
  - eadmund 4y ago
    > You are repeating an argument you read somewhere, not actually something you believe. I think I am a better judge of my beliefs than you are. > No-one sizes their terminals to 80chars. Mine open at 24×80, although to be honest I normally tile them instead. And I much prefer code formatted to be 80 chars wide, with functions that fit within a page or two of text.
    - sly010 4y ago
      > And I much prefer code formatted to be 80 chars wide, with functions that fit within a page or two of text. Wouldn't you agree that largely depends on the code in question? Of course I also "prefer" shorter lines in general, but that relationship is somewhat linear: 81 is not infinitely worse than 80. If the function in question would be more readable with just 1-2 lines that happens to be 83 chars, wouldn't you opt for that over placing some arbitrary closing bracket on the next line? Whether a code is more readable (for a human) should really not be decided by an arbitrary technical limit from 50 years ago. We have code reviews for that. btw, as far as I know the linux kernel has a _recommended_ 100 char maximum now.
nanoservices 4y ago
> Having worked at Google for many years Perfect person to ask this. What is behind the need to constantly abandon products/services in favor of new offerings that have a fraction of the functionality?
- Jensson 4y ago
  Because Google earns more money by making those engineers optimize ads rather than maintaining systems with a fraction of the ROI. The upper leaders even talked about that. How Google was looking for "the next big thing", and every time it turned out to just be be more ads since nothing else they tried even came close to being as profitable.
BeetleB 4y ago
I dunno - I strive for 80 characters and do Python development these days, and it isn't hard at all - with good editor support. Adding an extra parenthesis shouldn't hurt that much. I choose reasonable variable names, and almost never shorten them to get a line to fit in 80 characters. We don't have an 80 character rule, but none of the other developers has come to me saying my code is hard to read. The lambda problem is a language problem. If Python allowed multi-statement lambdas, you wouldn't have this frustration. When I used to do C++, most of my lambdas were multi-line - my coworkers found it easier to read.

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?

nextlevelwizard 4y ago
>There are tons of edge cases where allowing a 100k line of text would totally make sense Can you give one?
- Tepix 4y ago
  An art project!
  - nextlevelwizard 4y ago
    Yeah if you embed a random 100000 character art project as one liner in your code you have bigger problems than 100000 character line in your code.
- bob1029 4y ago
  Sure. Unit test where you have hundreds of signature specimens which need to be evaluated against graphics processing code. Maintaining a separate list of binary files for each resource was a mess for us. Inline base64 string in each unit test method containing the exact specimen was way more convenient. These lines are long but cause no trouble for IDE responsiveness or our github tooling.
  - the-lazy-guy 4y ago
    I think maintaining a directory of binary files and using it at runtime is a lot better in the long run. Either through a separate build step which embeds them into the test binary. Or via proper env setup where tests actually know how to find the data in the file system. At the very least you can inspect your test data easily without having to extract it from base64-encoded strings. Current approach may be working for your team, but I can totally see why a company which has a dedicated team working on build and testing infra, prefers a slightly more complex approach. It requires one-off investment in tooling which can be payed off very soon given enough people using it.
  - nextlevelwizard 4y ago

eadmund 4y ago

> Python requires extra effort to brake lines, often adding extra parentheses or doing other unnecessary tricks. There are much more compact languages than Python. > Now, I am so happy with 120 char limit while still being able to fit two columns on one screen. The standard width of a terminal is 80 characters; if you are writing 120-character-wide code then your lines will read very poorly on a terminal, or a window sized to a terminal. Note too that to be readable text should not be too wide, which is why newspaper columns are narrower, and why websites normally try to have a fairly narrow text box. It turns out that 80 characters wide is a pretty good readability standard.

sly010 4y ago
You are repeating an argument you read somewhere, not actually something you believe. No-one sizes their terminals to 80chars. Heck, I don't even remember the last time I came across one, maybe other than some BIOS over RS232 (i.e. NOT coding). For the 0% of you who code on a dot matrix printer, please enable line wrapping in your editor and let the rest of the world move on. I am not saying lines should be arbitrary long, but a 100-120 _soft_ limit would really not hurt anyone and would help code readability a LOT. p.s. even dot matrix printers support a 100 character mode. EDIT: long lines only reduce readability for prose. Code is inherently easier to parse for the eye because it has a shape. Unless of course if you f--k up that shape with arbitrary line breaks.
- eadmund 4y ago
  > You are repeating an argument you read somewhere, not actually something you believe. I think I am a better judge of my beliefs than you are. > No-one sizes their terminals to 80chars. Mine open at 24×80, although to be honest I normally tile them instead. And I much prefer code formatted to be 80 chars wide, with functions that fit within a page or two of text.
  - sly010 4y ago
    > And I much prefer code formatted to be 80 chars wide, with functions that fit within a page or two of text. Wouldn't you agree that largely depends on the code in question? Of course I also "prefer" shorter lines in general, but that relationship is somewhat linear: 81 is not infinitely worse than 80. If the function in question would be more readable with just 1-2 lines that happens to be 83 chars, wouldn't you opt for that over placing some arbitrary closing bracket on the next line? Whether a code is more readable (for a human) should really not be decided by an arbitrary technical limit from 50 years ago. We have code reviews for that. btw, as far as I know the linux kernel has a _recommended_ 100 char maximum now.

nanoservices 4y ago

> Having worked at Google for many years Perfect person to ask this. What is behind the need to constantly abandon products/services in favor of new offerings that have a fraction of the functionality?

Jensson 4y ago
Because Google earns more money by making those engineers optimize ads rather than maintaining systems with a fraction of the ROI. The upper leaders even talked about that. How Google was looking for "the next big thing", and every time it turned out to just be be more ads since nothing else they tried even came close to being as profitable.

BeetleB 4y ago

I dunno - I strive for 80 characters and do Python development these days, and it isn't hard at all - with good editor support. Adding an extra parenthesis shouldn't hurt that much. I choose reasonable variable names, and almost never shorten them to get a line to fit in 80 characters. We don't have an 80 character rule, but none of the other developers has come to me saying my code is hard to read. The lambda problem is a language problem. If Python allowed multi-statement lambdas, you wouldn't have this frustration. When I used to do C++, most of my lambdas were multi-line - my coworkers found it easier to read.