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.

[munificent]

we are finding deeply nested code, which leads to lots of space being wasted as pure indentation.

Increasing the column limit doesn't really fix that problem. You're still wasting just as much space on the left side of the page. You're just able to make the window wider and eat space on the right side of the page that you could be using for other things.

Some amount of nesting is, of course, natural in Flutter. But I don't think any page width is going to make >10 levels of indentation a good idea. That's just too much nesting for the eye to follow. Instead, I think a better solution is:

• Language and API changes to get rid of unnecessary indentation. In particular, any widget that contains a list of child widgets ends up using two levels of indentation when really only one is needed.

• Likewise, many widgets are conceptually more like modifiers than containers (think Center so I don't know if it's useful to burn a level of indentation on them as opposed to having them just adjacent to the widget they modify.

• Teach users to break pieces of build() methods out into separate helper methods. This resets the nesting, makes them reusable (I see a lot of copy/paste code inside build() methods), and lets you attach a meaningful name to it.

• Train users to be more proactive about breaking chunks of their build() methods out into separate widgets. Possibly investigate language or API changes to make this take less boilerplate to do.

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 do all of my work on a 15" laptop and very much appreciate being able to do side-by-side diffs, so going wider than 80 columns would be a significant challenge for me.

[feinstein]

The problem is when we are obligated to run dartfmt before each commit. this way we can't escape the laws of indentation, unless the Flutter team releases a new flutterfmt tool to help with this.

Also, breaking down into smaller Widgets is just swapping one problem for another. We reset the indentation, but now we have lots of boilerplate to code. Helper methods are in general not recommended . Also, sometimes splitting the Widget tree makes it easier to read when you care about the high level, but it also can make it harder, if you are trying to follow down the rabbit hole on where's the problem, and you find yourself going back and fort in the file, looking for different Widget classes, so it can be helpful or not, depends on the context.

I am not saying I am against breaking the build method, I do it all the time, it's just that sometimes it just doesn't make much sense, and if we use more specialized Widgets, like Provider and Consumer the tree will get even more nested and harder to find a logical place to isolate the code.

[munificent]

The problem is when we are obligated to run dartfmt before each commit.

You can pass --line-length=<value> to dartfmt to specify a custom column limit for whatever value you want. 80 is default, but this is one of the few places where it allows you to override that.

[feinstein]

I generally use Ctrl+Alt+L in IntelliJ IDEA, can't see an option in the plugin to pass this configuration :/

[deakjahn]

@feinstein I think that piece of advice about helper functions is about something entirely different. Not using mere functions instead of actual widgets. This has its clear reasons but that doesn't in any way forbid you from using helper methods inside your widgets. Basically:

@override
Widget build(BuildContext context) => InkWell(
      child: Stack(
        children: [
          _displayIcon(),
          _displayName(),
        ],
      ),
      onTap: () {
        if (onTap != null) onTap();
      },
    );

Widget _displayIcon() => CachedNetworkImage(
  // ...
    );

Widget _displayName() => Align(
  // ...
    );

instead of lifting the CachedNetworkImage and the Align (and everything that comes below it) up to the first function. I do it all the time for readability and it makes my life much easier.

Having said that, I wholeheartedly agree with the lifting of the 80 character limit which I have always found hilariously low in the age of 28-30-whatever monitors. And even on laptops.

[deakjahn]

@feinstein by the way, if you go into Settings > Editor > Code style > Dart > Dartfmt, you'll see that it does pick up the width from another tab. Although I'm not sure it really does make any difference. :-)

[feinstein]

I know that changing my code helps, but I feel this is like Apple saying "you are holding it wrong".

I just don't want to write additional code when I think my actual code is OK, just too much to the right. It's like creating a new problem for fixing an old one.

[greglittlefield-wf]

As another data point, I did a search and found that ~35% of our organization's Dart projects (maintained by various independent teams) use a custom dartfmt line length of either 100 or 120 as opposed to the default 80.

And, almost all of those repos with custom line lengths contain over_react UI code, which has similar nesting/syntax to Flutter widgets.

[keomaborges]

PSR-12 defines the concepts of soft limit and hard limit:

There MUST NOT be a hard limit on line length.

The soft limit on line length MUST be 120 characters.

Lines SHOULD NOT be longer than 80 characters; lines longer than that SHOULD be split into multiple subsequent lines of no more than 80 characters each.

There MUST NOT be trailing whitespace at the end of lines.

Blank lines MAY be added to improve readability and to indicate related blocks of code except where explicitly forbidden.

There MUST NOT be more than one statement per line.

I think it is quite fair and looks nice for PHP. There might be something similar for Dart as well. In my opinion, 80 and 120 would be great.

[munificent]

As another data point, I did a search and found that ~35% of our organization's Dart projects (maintained by various independent teams) use a custom dartfmt line length of either 100 or 120 as opposed to the default 80.

Sure, but another way to look at that data point is that ~65% of your teams are using the 80 character line length, which implies that it's the right choice to standardize on.

[ErliSoares]

As another data point, I did a search and found that ~35% of our organization's Dart projects (maintained by various independent teams) use a custom dartfmt line length of either 100 or 120 as opposed to the default 80.

Sure, but another way to look at that data point is that ~65% of your teams are using the 80 character line length, which implies that it's the right choice to standardize on.

They are using 80 characters per line does not mean that they think it is better, most programmers I know do not agree that 80 is better, but use it as a guideline.

Part of the projects is 80 characters per line and part 120, but if the guideline changes to 120 everyone would use the same pattern.

[deakjahn]

No, Bob, it isn't. You can be as opinionated as you please in other corners of dartfmt, especially if, as right now, good placement of empty comments allows us to influence the formatting in many cases, but don't force line lengths on us, keep it a setting. Not everybody works in teams. Not everybody uses 14" laptop screens. Not everybody actually cares about old-fashioned ideas why the 80-limit should be better than anything larger of having no limit at all or whatever. It's really understandable that, for the sake of uniformity, you never wanted to introduce hundreds of user changeable settings. During the last year or so of working in Flutter I've grown to actually like the way dartfmt works (and in the few cases where I have differing opinion, I simple use those extra comments) but I'm sure to switch it off the minute you decide to rob the line length setting from us. I like working on a 30+" monitor and I want to use it all, not just the left quarter strip.

[vincevargadev]

There are advantages to embracing a universal line length limit in the community. It's the tabs-vs-spaces and other endless discussions happening all the time in all programming communities (e.g. Python's PEP8). This reminds me of the Go Proverb:

gofmt's style is no one's favorite, yet gofmt is everyone's favorite.

I don't really care if it's 80 or 100 characters, what I do not want is every package on pub.dev using different styling conventions and buggy, complex tools.

[feinstein]

As I said in my original post, the 80 character line was made for newspapers and magazines, so eye movement be constrained to a region, this way reading would be more comfortable and easy to matain attention on the text.

But in Flutter we get lots of whitespace indentations on the left, making the text more like a zigzag pattern, not the same as a newspaper.

So here's a crazy idea to explore and research:

80 character lines counted after the first non-whitespace character in that line (left most whitespaces should be ignored on the character count).

This could be coupled with IDE tools that auto-scrolls the text left and right, keeping it bit centered as we scroll it up and down (but not perfectly centered, so we still get a sense of indentation as we scroll).

Is this good? Will it work? Will code be easier to read? Is this ridiculous and will it fail miserably? I have no idea, but I would love to see some research done on it, that's how science evolves afterall, crazy hypothesis being tested so we can come up with new ideas and new hypothesis based of the previous ones.

[deakjahn]

@feinstein The 80-char has nothing to do with newspapers and magazines. That's an afterthought somebody tried to make up to justify that very old rule that simply goes back to the monitors of several decades ago.

[feinstein]

Independently, my suggestion is based on the fact that Flutter code has lots of leading whitespaces, whereas normal texts does not, so my suggestion stands.

[feinstein]

It appears that Linus Torvalds agrees with us:

https://www.theregister.com/2020/06/01/linux_5_7/

[munificent]

don't force line lengths on us, keep it a setting.

There are no plans to remove the option for specifying line length when running the formatter.

[shinriyo]

I want auto formatter when saving.

[munificent]

It appears that Linus Torvalds agrees with us:

https://www.theregister.com/2020/06/01/linux_5_7/

Linux uses 8 spaces of indentation, though, which Dart does not.

[lukepighetti]

This, to me, is the most frustrating pain point of Dart. We can run dartfmt with any line length we want, we can set up a single IDE to format with any line length we want, but we cannot enforce this project & IDE wide with a pubspec.yaml setting. I have no problem with https://pub.dev removing 20 points if someone doesn't use an 80 character line length. This isn't about public projects, this is about internal projects.

The only compelling argument I've heard against finalizing this feature is "because I don't want to," which honestly, is a fairly compelling argument in open source as far as I'm concerned, but it doesn't make it any less frustrating and senseless. I understand that maintaining dartfmt probably feels like taking on an army of slobbering screaming orcs with nothing but an xacto knife, but give the community a little bit of credit on this one @munificent .

[MrCsabaToth]

Even with 100 I can easily split the editor window vertically. 80 is so limited that it breaks even short+dumb code lines into multiple lines -> the brain has to work more cognitively to unwrap the riggidy broken lines.

[azimuthdeveloper]

Just dug this up. I have a line length configured on my computer, and another one configured on my laptop. I have to remember, in my brain, the line length I have set, otherwise, I save files, and then it makes a git diff a total nightmare.

Also, this comment:

I do all of my work on a 15" laptop and very much appreciate being able to do side-by-side diffs, so going wider than 80 columns would be a significant challenge for me.

That's nice, and would relevant if you were the only person that used Flutter to develop apps. But you're not. So it's not relevant. And even if it was too wide or whatever, you could configure it by setting it in the pubspec.yaml as required.

[MrCsabaToth]

Just dug this up. I have a line length configured on my computer, and another one configured on my laptop. I have to remember, in my brain, the line length I have set, otherwise, I save files, and then it makes a git diff a total nightmare.

Also, this comment:

I do all of my work on a 15" laptop and very much appreciate being able to do side-by-side diffs, so going wider than 80 columns would be a significant challenge for me.

I work on a laptop, 1920x1080 so nothing fancy and I can side-by-side 100 or even longer files.

[Levi-Lesches]

I see there are two main arguments: 80 characters is standard, > 80 characters can look nicer. I think having the option for both should make everyone happy.

Since we can already override dart format, can there be another lint option too? Right now it's lines_longer_than_80_chars or nothing, but I agree that there should be some limit in a project. How about adding lines_longer_than_100_chars and lines_longer_than_120_chars as well?

[gpeal]

I don't think it's particularly useful to try and make an argument that 80 lines should always or never be used. Ultimately, I think the ask here would be to allow teams to make their own decisions via configuration.

[feinstein]

It's already possible to pass a flag for this configuration. The original post was about what character limit per line should be the official recommendation or default option.

For example, in my team we use 1000 characters as a limit in the dart format tool (PRs aren't allowed to be merged if there's a formatting issue), which is basically just saying that we don't want to limit.

Why we don't limit? Because we believe breaking code lines at each 80 characters can make code harder to read, which is the opposite of the original intention of the 80 characters limit. In my team the devs usually make cleaner line breaks than the tool with 80 characters, but I don't know if this applies to everyone.

[MrCsabaToth]

It's already possible to pass a flag for this configuration. The original post was about what character limit per line should be the official recommendation or default option.

There is a command line flag but you cannot bubble your custom settings down to everywhere in the toolchain. In some places the 80 still pops up.

Another thing is that I would like more detailed command line switch. My apps have generated code (Floor and Mockito generate code). These of course use the default 80, and once that goes through my custom setting ti unnecessarily changes those files.

[gsouf]

I think the main problem is rather pub.dev warning, isn't it?

[deakjahn]

If it was just a warning... But it's a hard error.

[rafaelcolladojr]

Let's just meet half-way and make the default 100.
Can't tell you how many times my lines have been split because of a couple (<=10) characters...

[Kravchenko32]

Let's just meet half-way and make the default 100.
Can't tell you how many times my lines have been split because of a couple (<=10) characters...

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.

[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 dart-lang/pub-dev#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 dart-lang/pub-dev#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 ?