Rethink the 80 characters line limit

[feinstein]

I am not sure if this is the right repository to discuss this, but I would like to propose a investigation if 80 characters per line should still be the recommendation and dartfmt default.

The Dart style guide says:

Readability studies show that long lines of text are harder to read because your eye has to travel farther when moving to the beginning of the next line. This is why newspapers and magazines use multiple columns of text.

I think this is perfectly valid for regular text for newspapers and magazines, that usually come in the form of:

Lorem Ipsum is simply dummy text of the printing and typesetting industry. Lorem Ipsum has been the industry's standard dummy text ever since the 1500s, when an unknown printer took a galley of type and scrambled it to make a type specimen book.

But recently with the soaring success of Flutter, we are finding deeply nested code, which leads to lots of space being wasted as pure indentation. This picture shows how one of my Flutter widgets has just about half its line wasted in indentation, forcing me to break lines all the time:

Bear in mind, this is just a 9 Widget deep tree: Provider>Scaffold>SafeArea>WillPopScope>Column>Consumer>Padding>Row>Text.

And I didn't have any classes there with long names. If I did, it would have been a multi-lined mess.

IMHO, we can't use studies made for newspapers for coding styles, specially after the usage has become so different in the Flutter age.

I have seen people in the past defending 80 character lines saying it fits better all monitors, but nowadays with everyone using 24" monitors 1080+ I don't think that's longer the case.

I don't want to propose a new number, like 120 characters, but instead I would like to suggest that Google should launch a research on this, taking in consideration Flutter Apps and what line character count fits better their code.

My hope is that we don't turn out in the end with just 40 characters per line as real usable space due to indentations and enforced standards.

[MrCsabaToth]

Just stop using Dart. After a week of making changes to mangled flutter code we have, I’m done, it’s utterly unreadable. 80 character limit isn’t the issue though, the issue is that bot formats your code, and all bots are tone-deaf and have zero understanding of what’s human readable or which parts of code are actually important.

flutter format uses dartfmt under the hood, I guess you'd want to customize that. I don't see customization features with a simple search, maybe it's worth filing a ticket requesting that if a deeper search doesn't find options.

Ditching Dart would mean abandoning Flutter which would be kinda drastic.

[rafaelcolladojr]

We're mad, but not that mad.

[deakjahn]

Just stop using Dart.

Considering that I'm hardly the only one who considers Flutter to be better than any other contemporary mobile cross platform framework, by a long sea mile, this is rather unlikely... :-) In your IDE, where reading your own code counts, you can change the line length setting. The only problem is when you want to publish packages for others but, frankly, if you're at the stage when you abandon ship that easily, I don't think this is an issue yet.

[rirjkl19]

I prefer the 80 line format. Kind of way to identify for me if a widget is too nested. Some devs prefer adding a conditional statement in the widget tree which in my opinion should be avoided if possible.

It makes the widget tree more readable in a sense you don't have to read a widget tree both horizontally and vertically.

Should the screen/page/stateless/ful is huge. Just properly separate it in a widget class which makes sense.

Don't hate please. Just stated my opinion based on experience of having a peer code review for a long time.

[gsouf]

@rirjkl19 I get your point about forcing to not nest code, but still 80, 100 or 120 would not make a big difference for nested code and giving more screen space for a single line does not prevent people to be good developers

[Maartyl]

voting for controversial opinion: Make it 80 after indent. Why:

• One can comfortably fit a secondary tool next to code, like widget inspector, or a reference file.
• This assumes horizontal scrolling. Most of the code that fits on a page vertically is usually at similar indent level. The IDE can help with it. Maybe a shortcut for "fit horizontally based on visible lines". Maybe even optionally automatic as part of scrolling.
• The "newspaper" argument has some merit for long comments, and it makes sense to wrap them, however the opposite problem is much worse. Long comments are horrible, when half of width is already taken by indent. Not only do I find it harder to read them super-wrapped, but they now take huge number of lines, and actual code is sparse and again, hard to read.
• Occasionally, comments and code become an unreadable noodle with lots of unused space to the left of them. [1]
• This does not require making existing viewports wider, or changing the number from 80 (surely leading to more argument which exact number is best. Maybe 128?!? 😅).

This will work especially well with viewport wider than 80, as almost all code on visible lines will fit. (except for rare, extremely "leaning" code, which tends to not have long lines anyway)

(The more code I see at the same time, the more productive I am. Good syntax highlighting mostly solves code being too dense. (assuming a readable language like Dart) Not forcing newlines everywhere, or 4 space tabs is great, and I very much appreciate it!)

---

[1] Yes, all of this can be solved with refactoring, and arguably, in many cases, it is better to do so. But there are also many valid cases, where it's not.

---

I don't think any absolute limit will ever be a good solution. People who feel they need +10 today, will equally need +10 then.

Monitor widths are not a good reference point. Neither annoyingly limiting to 800x600, neither expecting everyone to have HD widescreens, nor expecting any point in between. It should work on all, without being annoying, using as much space as the user desires, without forcing it on others. (btw. for thinking in limits: in distant(?) future, assuming AI won't take over coding, it's possible screens will be mostly replaced by lightweight VR/AR, with "screen width" limit being effectively 360° around you... (well, even more, possibly, as especially programmers might even opt for non-Euclidian work spaces. 😂)) - Anyway, point being, it is not a good metric to base code formatting on, except for requiring at least some minimum. And keeping 80 for that minimum seems reasonable to me.

[philipmjohnson]

As a 64 year old programmer, I just want to comment that the 80 character line limit is rooted in the days when we used punch cards to represent lines of code, and there was a lot of inertia for a few years afterward to maintain backward compatibility.

Please recall that in those days, a significant amount of programming was done in assembly. So 80 characters seemed like a very comfortable amount of line width.

I think there's a strong argument to be made for creating tools that enforce consistency within a project or development group. I think it's problematic to argue for "One line width to rule them all."

[jamesderlin]

I strongly disagree with some of the requests to have a line length limit that ignores indentation. Doing so would mean that lines could be arbitrarily long, and therefore there would never be an editor/terminal/window width wide enough to guarantee that all lines are fully visible without horizontal scrolling or wrapping. That seems like a compromise that would be bad for everybody.

I think ideally there would be no set length limit and that editors/terminals/windows could reformat code dynamically based on their current width. But that's probably not realistic for non-IDEs.

Otherwise I don't think it's possible to reach any kind of consensus on what any specific line length limit should be. I personally use 80-column terminals, so I like 80, but I also recognize that that's not everyone's cup of tea. I do think that there should be a way to specify the preferred line length per-project instead of per-user. Making dart format honor max_line_length in an .editorconfig file probably would be nice.

[deakjahn]

@jamesderlin I don't know in VS Code (I use it for many things but not Flutter, it just happened that way) but in Android Studio, you can set it to your line length, I always have it at 999 what practically means no line length.

As I have already mentioned above, it's not a problem in a sane IDE, you can set it to whatever you like, so there's no need to try to convince each other of the perfect line length. The problems is with places like Pub.dev where a specific setting is enforced.

[jamesderlin]

The problems is with places like Pub.dev where a specific setting is enforced.

Then that should be an issue filed against the pub.dev repo, and it looks like there already is https://github.com/dart-lang/pub-dev/issues/3041.

[yolowex]

Yeah the dart development team needs to understand that not everyone is using a tiny monitor.

[techwn]

As I have already mentioned above, it's not a problem in a sane IDE, you can set it to whatever you like, so there's no need to try to convince each other of the perfect line length. The problems is with places like Pub.dev where a specific setting is enforced.

I totally agree with this, which is followed by https://github.com/dart-lang/pub-dev/issues/3041.

[hbock-42]

Just give us a config file where we can set line length per project, nothing else ... This is ridiculous, I am working solo on the mobile part, but will have to onboard new members soon. I praised dart and flutter, easy configuration project wise (linter file), but I forget the line length is per user. I tried to convert back to 80 line length just to see how it renders, and this is seriously ridiculous, even on a laptop ... I mean I am not coding on a tablet...

[Dynesshely]

Just give us a config file where we can set line length per project, nothing else ... This is ridiculous, I am working solo on the mobile part, but will have to onboard new members soon. I praised dart and flutter, easy configuration project wise (linter file), but I forget the line length is per user. I tried to convert back to 80 line length just to see how it renders, and this is seriously ridiculous, even on a laptop ... I mean I am not coding on a tablet...

I totally agree with this comment

We can consider setting the maximum length of each line in the lint configuration file Avoid using dart format's default maximum length per line Similarly, this item should also be followed in the score of pub.dev to detect Different projects may have different maximum length settings for each line If this configuration cannot be made to depend on the project, it will not be friendly to distributed collaborative development projects.

Consider an open source project. New contributors may not necessarily read the contributing file in detail, or there may be no such file at all. If these automatic formatting settings can be determined by the lint configuration file, and vscode or plug-ins on other platforms can also Following these settings, it will become very user-friendly, and developers only need to focus on the code logic.

[hbock-42]

I think at this point it's just that they want to show us THEY get to choose those stuff, there is zero good reason not to add this feature but they don't want to admit they are wrong so they will just prevent us from having this basic and very needed functionality

[deakjahn]

Dart format was opinionated, always, and Munificent (Bob) was always vocal about it. It usually grows on you, the more you use it. Only that I always thought that it could be opinionated inside the constraints but the line length is such a constraint that should be removed from format and dictated from the outside.

[jamesderlin]

I think at this point it's just that they want to show us THEY get to choose those stuff...

Let's try to keep the discussion constructive and to not be overly dramatic. If your claim were true there wouldn't be a way to configure line length at all.

[Dynesshely]

I think at this point it's just that they want to show us THEY get to choose those stuff...

Let's try to keep the discussion constructive and to not be overly dramatic. If your claim were true there wouldn't be a way to configure line length at all.

How about put the configuration in analysis_options.yml ? If no this file or no this configuration in this file, we keep 80 per line ?

[y-nk]

5 years to get dart format to respect .editorconfig and still nothing. i wonder how you can advocate to build such as flutter (which builds apps for end users) when you don't listen to your own users. there's one level of stubborn-ness, but this is something else. i'm sure people of this thread complaining remain on dart by constraint rather than by choice, and if anything will kickstart a non-dart project as soon as they can (to what repo owners may answer: "yeah cool thx bye")

[deakjahn]

No, you're not right. I use Flutter (and Dart) because of my own choice, because I consider it the best available cross-platform framework, and not just by one long sea mile. I had my fair share of criticism of this 80-char limit, and still. Format always was opinionated, from the very start, Munificent (its author) was always vocal about this. I have no idea, either, how we could convince him that as correct as he can be on other topics, he isn't on this one, but that doesn't make me abandon ship. Very, very, very far from it.