RFC: change oxfmt default print width from 80 to 100

[Boshen]

One of my goals for oxfmt is zero configuration.

Across all the repositories I’ve set up, I’ve always had to change printWidth to 120 because the default of 80 isn’t wide enough.

Many projects configure their print width above 80, despite Prettier recommending otherwise (https://prettier.io/docs/options#print-width).

Some reasons include:

• 4K and Retina displays provide more horizontal space.
• TypeScript code tends to be longer than JavaScript due to type annotations.
• Import statements often contain many items.

It occurred to me that I’ve never set a printWidth for Rust, and only discovered today that Rust’s default is 100. Research also shows that newer programming languages use 100.

After comparing 100 and 120, I find 100 more pleasant and easier to read. With 120, my eyes have to travel significantly farther across the screen. 120 may also be too wide for IDEs that have left and right sidebars on a 14 inch laptop.

Therefore, I propose changing the default to 100.

I believe this breaking change is acceptable for existing projects because:

• A migrator will automatically migrate printWidth: oxfmt: --migrate prettier #15849
• .editorconfig’s max_line_length will continue to work as expected: oxfmt: respect .editorconfig #15850
• Most users will find the newly formatted code at printWidth = 100 easier to read.

Overall, this should remove one line of setting or a configuration file for some projects.

---

Bonus point: larger printWidth = less LLM tokens.

---

Github searches:

printWidth: 100: 24.4k https://github.com/search?q=printWidth%3A+100&type=code
printWidth: 120: 27.3k https://github.com/search?q=printWidth%3A+120&type=code

---

ChatGPT on default width:

Formatter / Language	Default Width	Notes
Prettier (JS/TS/HTML/CSS)	80	Configurable (printWidth).
Biome (JS/TS)	80	Matches Prettier philosophy.
Ruff Formatter (Python)	88	Mirrors Black’s default.
Black (Python)	88	PEP 8–influenced; chosen for readability.
gofmt (Go)	None	Does not wrap lines; no max width.
rustfmt (Rust)	100	max_width = 100; chosen for Rust ergonomics.
ClangFormat (C/C++/Obj-C/etc.)	80	ColumnLimit = 80 for LLVM/Google styles.
Google Java Format	100	Not configurable.
ktfmt (Kotlin)	100	Google-style Kotlin formatting.
swift-format (Swift)	100	Default lineLength = 100.
PHP-CS-Fixer / Pint (PHP)	120	Common default in PHP ecosystem.
Perl perltidy	80	Default maximum-line-length = 80.
Elm Format	80	No configuration; fixed width.
Haskell Ormolu/Fourmolu	80	Fourmolu configurable; Ormolu fixed.
OCamlformat	80	Default margin = 80.

[connorshea]

For reference from Ruby with the main linter there, Rubocop defaults to 120: https://docs.rubocop.org/rubocop/cops_layout.html#layoutlinelength

[mhsdef]

Dig it, at 100.

mix format (Elixir) is at 98 characters by default if you want to add that to your table too.

[pompydev]

I support print width of 100 but to be the devil's advocate, most people prompt AI from the sidebar of their IDE and print width of 100 might be too wide when people have sidebar open on both sides.

[bai]

We always change our defaults to 120.

Working at 80 even with 2 sidebars sucks. I even prefer line wrap + 120 to having strict 80.

[nebularyu]

Keep your compatibility and gain more adoption.

[pompydev]

I doubt having different default printWidth will stop anyone from adopting oxfmt

[lomby92]

At work, we use 120 in every language (PHP, JS, Dart) and it fits very well.

In my experience, meaningful names for variables and methods require space to not break the reading flow. At the same time, something greatest than 120 should be split in more lines because of one of these reasons:

• there are many parameters in the method, show one for each line
• the name of method/variable is way to long, rethink it or it will not be usable/readable

Another reason: today most of the code is TypeScript and writing the type requires space

[ryanleichty]

45–90 characters is the general rule of thumb for line length typographically, so I think 100 makes sense as a good default

[synecdokey]

80 is great when you use two panels on a 14", if you don't use a sidebar. Also makes 3 panels on a 27" an option.

I tend to advocate for using the defaults, especially when they're long established, but if oxfmt diverges from every other js/ts formatter, we'll have to customise that to go back to 80.

It's also a non-starter on any project that is using 80 if you don't want your immediate inline git blame to become entirely useless.

[danielwaltz]

This was my initial thought too, though particularly in my case it's two panes with terminal sidebar always open. Anything over 80 and I'm out of room.

As far as defaults go though, I'm totally ok with that changing! An editor config file is simple to set up, and maybe hot take but I think if you don't already have one in your codebases you should.

I think keeping it one way just because that's how it's always been isn't the play. If there's a opportunity to shift based on today's landscape, then go for it!

Also extra food for thought, I do think keeping line length in check for terminals is important too. I can't look up what the line length for this would be, but I would be inclined to clamp my line lengths so running cat on a file won't wrap or get cut off in a full screen terminal using 16pt mono font on a 1280x720 display.

[Boshen]

• feat(formatter)!: Default to lineWidth: 100 #15933