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.
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.
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.
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.
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.
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.
Are the tools at Google and elsewhere unable to diff code if a line exceeds some 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 just have to convince your reviewer it makes sense in that particular case. The more obvious it is, the easier it will be.
Can you give one?
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.
Of course you can embed binary files as base64, but have you thought if you should
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.
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?
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.
On my team we've settled for either 100 or 120 depending on language.
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.
[0] https://www.viget.com/articles/the-line-length-misconception...
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.
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.
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.
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.
The other fact is that few devs craft their code to fit 80 characters. Instead they write code and let formatters do their thing. But automated formaters are doing a horrible job, aka if I write a line that is 81 characters long, they will massacre it to a set of unreadable lines with no proper aligning.
So now we are at the mercy of automated formatters that try to enforce an arbitrary constraint that is irrelevant with today's code editing/reviewing technologies.
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.
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.