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.

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.

> 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.

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.

> 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.

> 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.

And then you get Go readability reviewers enforcing a single letter (!) variable names so that everything fits in 80 columns. Do you prefer that?

Line splitting in python is miserable, all the other languages are much easier for it.

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?

The tools at Google are perfectly capable of diffing lines of arbitrary width.

Those in charge of the C++ style guide choose not to allow them without strong justification. In practice, you just convince your reviewer and move on. Most reviewers are reasonable, but edge cases a where it is needed are rare.

I don’t especially like it, but in terms of annoying style issues, it is very far down the list, especially when the tooling handles it all for you via auto formatting and whatnot.

You can commit lines > 80 characters in all languages.

You just have to convince your reviewer it makes sense in that particular case. The more obvious it is, the easier it will be.

>There are tons of edge cases where allowing a 100k line of text would totally make sense

Can you give one?

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.

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.

Why does it need to be in the same test file at all? That sounds like a test resource that should be in some kind of test material/resources folder where it can be read from.

Of course you can embed binary files as base64, but have you thought if you should

An art project!

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.

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.

> 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?

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.