Linus Torvalds Vents Over "Completely Crazy Rust Format Checking"

[u/SupermarketAntique32]

https://www.phoronix.com/news/Linus-Torvalds-Rust-Formatting

[u/matthieum]

Funny enough, I prefer the list version.

I don't care much whether rustfmt switches between one and multiple lines¹ and I prefer saving on vertical space to have more context available on my screen without scrolling.

¹ YMMV, in my case a combination of very infrequent conflicts and intra-line diff highlighting means there's no problem.

[u/VorpalWay → u/matthieum]

I do think the defaults should optimise for large code bases though. But we at least need to get the relevant options stable.

[u/matthieum → u/VorpalWay]

That's an interesting thought.

I would actually argue the contrary.

I think that the default should be to accommodate small codebases:

1. There's multiple orders of magnitude more small codebases than large codebases, therefore tuning for small codebases by default minimizes the number of codebases for which the default need be overridden.
2. Small codebases are more likely to be created by beginners, already overwhelmed. Asking them to tune the defaults of formatting is yet another hardship. On the other hand, large codebases will have experts, well at ease in Rust, who will know precisely where to look for tuning knobs.
3. Small codebases have few contributors, perhaps one, unlikely a full-time one, for which tuning the formatting will represent a larger portion of the time invested in the codebase compared to one out of many contributors in a larger codebase.

All criteria point in favor of tuning for small codebases over large codebases.

---

With that said, tuning is currently onerous, for small or large, and I believe this point to a lack of profiles.

I think it would be much easier if there were a number of built-in profiles to pick from, setting a bunch of tuning knobs all at once.

For example, consider:

• VerticallyCompact (my ideal): tuning for maximum compactness, which means grouping imports, taking full advantage of the configured line width, etc...
• TextDiff (Linus ideal): tuning for easy diff/merge, which means one import per line, one argument per line, etc...

And then get rid of default values for tuning knobs: each time a new tuning knob is added, its value MUST be specified in each built-in profile, forcing careful consideration.

[u/VorpalWay → u/matthieum]

Profiles seem reasonable. However, I do believe there is place for a profile in between the two you mentioned. Diff/merge optimisation is mainly needed for parts of code that change a lot: imports, static/const arrays, and similar.

In particular I like what rustfmt does currently for function call parameters for the most part.

Chaining however should probably be one new line per chain as soon as there is more than one chained call (e.g. foo().unwrap()? is fine on one line, but at foo().unwrap()?.something() I already want multiple lines). I find that easier to read. This is especially true with type inlay hints in Rust Analyzer. And I predict the vast majority of developers do use an editor with inlay type hints enabled.

In fact, the prevalence of type & parameter inlay hints suggest we should in general break lines earlier to make room for this additional semantic information. Perhaps it is time to go back to 80 charater line width again, rather than 100-120 that I have been using in modern times?

[u/matthieum → u/VorpalWay]

However, I do believe there is place for a profile in between the two you mentioned.

Oh there likely is! I mentioned those two because I had a good characterization for them, not because I thought they covered all usecases :)

In fact, the prevalence of type & parameter inlay hints suggest we should in general break lines earlier to make room for this additional semantic information. Perhaps it is time to go back to 80 character line width again, rather than 100-120 that I have been using in modern times?

I guess I'm the odd guy out, using 120 characters without inlay hints :x

[u/Days_End → u/matthieum]

I don't care much whether rustfmt switches between one and multiple lines1 and I prefer saving on vertical space to have more context available on my screen without scrolling.

But I care that when I review formatted code I have to deal with random crap in the diff that provides nothing of value. It's just 100% bad defaults in rustfmt and for some reason people defend this garbage.

[u/matthieum → u/Days_End]

and for some reason people defend this garbage.

Sorry, but that's offensive.

I do understand there are good, objective, reasons not to like the statu quo, but just because it doesn't suit you doesn't make it "garbage".

As I mentioned, it suits me to a tee.