Should formatting be customisable? How?

[nrc]

In the short-term, we need ways to experiment with how Rustfmt formats. However, what should the long term look like? There are wins if all code looks the same in terms of adjusting to new projects, and this approach is taken by Gofmt. On the other hand, we can never please everyone with a single formatting style, and people using Rustfmt with different styles is better than people not using Rustfmt at all (and the Rust community is not as 'conformant' as the Go community); this approach is taken by ClangFormat.

Currently, we have a rustfmt.toml file with many disparate options. If we do decide to keep some customisation, we should at the least decide on a strategy for what kind of options we want to present and how they are organised.

Finally, we have some options for introducing 'speed bumps' to customisation, we could:

• only allow customisation on nightly (vs stable or beta), this somewhat follows stabilisation policy for Rust)
• only allow customisation on Rustfmt build from source, rather than from distributed binaries
• only allow customisation of rustfmt, but not cargo fmt (I think this one is a terrible idea, but brain-storming...)
• opt-in to customisation with a command line argument or environment variable
• rustfmt distributed with Rust (some day, assuming this happens) does not permit customisation, but you can download a separate version which does.
• sure there are others

The idea with these speed bumps is we more strongly encourage users to use the default formatting, but permit customisation where it is necessary (e.g., corporate pressure, interaction with existing codebases, bloody-mindedness)

[joshtriplett]

This also ties in with the RFC procedure. If RFC proposers have to add an option to rustfmt for the new behavior, then the new behavior must necessarily have an associated option.

For something we don't want to support customization of, and want to require a single style for, we don't want an option. Given that, we'd either need to use one of the procedures @nrc suggested above to avoid exposing that option (e.g. only allowing it in nightly), or allow the RFC proposer to instead provide a rustfmt PR that changes the behavior to implement the proposal without adding an option.

[steveklabnik]

I am in favor of no customization options, personally. That said, I do recognize that this is a harder fight since we've waited so long.

@wycats has said it before, but basically, if a significant amount of the community wants to customize rustfmt, we've failed. And the standard library certainly should use it without options, to lead by example.

[joshtriplett]

@steveklabnik I agree entirely. Formatting is such a bikeshed topic that I think we're better off making a reasonable call (one that at least a significant subset of people prefer) and declaring it as "the style". Consistency has more value than the vast majority of individual formatting decisions.

[bruno-medeiros]

@steveklabnik @joshtriplett I disagree, I think rustfmt should offer some degree of customization. Yes, we should have a default/preferred Rust style, but I think rustfmt should allow some deviation from that preferred style.

One good example is max-line-width. This is more than a bikeshed option, there is no way one can determine a default value that works well for everyone, even if people are forced to "get used to it". This is because preferred max-line-width will be heavily dependent on the users monitor and IDE/editor setup. Some users might work a lot from a laptop, on the go, as such not have much monitor width available because of smaller monitor, and thus prefer a small max-line-width. Other teams might work in fancy offices with huge dual widescreen monitors, and heaploads of monitor width available. Another variation on this is users liking tinier fonts or not. Or using fullscreen editors, vs editors/IDEs with additional side-views.

Another case that was mentioned in different issue and will most likely require an option as well, is whether rustfmt should break string literals - or more generally, if the formatting can change the token structure of the source code. I think by default it should only change whitespace, and only with an extra option should it break string literals and other similar tokens.

There are likely to be more niche formatting aspects where no customization options might be too restrictive in practice.

[steveklabnik]

Even with those different ways to show things, people may _want_ to make them different, but I would still argue that they shouldn't. In Ruby, virtually every bit of code I'd ever seen in the open-source world uses 80 cols, even though they don't have a formatting tool.

[bruno-medeiros]

@steveklabnik And because Ruby does it, does that necessarily mean it's a good thing for Rust to do it as well? I'm skeptical of that. Unless you explicitly want to enable a similar culture and mentality as the Ruby community has - which I would argue is bad thing. Rust and Ruby seem one of the most opposite languages in the language spectrum I can think of. (I should probably come clean in that I am very biased against Ruby and dynamic languages in general - but that is a subject preference, yes, can't say much more about it)

One objective observation though, is that Ruby is in general much, much less verbose than Rust.
As such, one can argue that setting 80 as max cols is probably fine for the vast majority of Rubyist because it is a relatively large max line width for Ruby, no?

[steveklabnik]

I'm saying that I have previous experience in other language communities
where this has worked well, not that Rust should always do what Ruby does.
There's a large number of reasons to choose a single, global style, even if
it's not absolutely perfect in specific situations.

You are right that Rust is much more verbose than Ruby; that's why the
original 4/100 setting was chosen. That said, a lot of people do write 2/80
or 4/80 code in Rust. I'm not sure that the need for 100 is actually real.

On Tue, Sep 6, 2016 at 10:34 AM, Bruno Medeiros notifications@github.com
wrote:

@steveklabnik https://github.com/steveklabnik And because Ruby does it,
does that necessarily mean it's a good thing for Rust to do it as well? I'm
skeptical of that. Unless you explicitly want to enable a similar culture
and mentality as the Ruby community has - which I would argue is bad thing.
Rust and Ruby seem one of the most opposite languages in the language
spectrum I can think of. (I should probably come clean in that I am very
biased against Ruby and dynamic languages in general - but that is a
subject preference, yes, can't say much more about it)

One objective observation though, is that Ruby is in general much, much
less verbose than Rust.
As such, one can argue that setting 80 as max cols is probably fine for
the vast majority of Rubyist because it is a relatively large max line
width for Ruby, no?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#3 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AABsilY4o29gP1PM_eDINxUaHzvXQAXuks5qnXncgaJpZM4JrVwq
.

[gnzlbg]

I use some unconventional formatting: 2 spaces/80 char hard line limit. From past discussions I think that 4 spaces / 100 char hard line limit is going to win, which obviously hurts my feelings a bit.

Still, even if a style that I hate gets approved, I am strongly against customization options of any kind.

Consistency, and not having to have a style discussion ever again makes us all more productive. This is more important than my feelings.

In those particular cases in which one wants to manually format something, a escape hatch in form of e.g. a scoped comment (// rust-fmt off/on) is enough.

[bruno-medeiros]

Still, even if a style that I hate gets approved, I am strongly against customization options of any kind.

Consistency, and not having to have a style discussion ever again makes us all more productive. This is more important than my feelings.

Enforcing consistency on language code on a global level seems like "totalitarianism" to me, so to speak. Consistency should be enforced on a project, team or organizational level, but not globally. (and ideally this would similar or identical to the standard/global style - but we don't live on a ideal world)

[gnzlbg]

Enforcing consistency on language code on a global level seems like "totalitarianism" to me

It is, style just becomes part of the language, which isn't necessarily bad.

Consistency should be enforced on a project, team or organizational level, but not globally.

Why? What do we gain by not enforcing it globally? What do we loose if we enforce it globally?

The moment your project/team/organization uses an external crate with a different style one needs to adapt to a new style, from reading source code, to debugging, fixing bugs, enhancing the crate, and then there is the issue of maintaining an internal fork and merging upstream changes (either you end up with multiple styles within your organization or you need to reformat back and forth).

I just think that the benefits of a single style greatly outweight the cost of "getting used to it during the first week".

[Hrothen]

Enforcing a style globally doesn't actually mean it gets used globally, it just means people who don't like it can't use the standard formatting tool.

There are basically no benefits to having a single global style, it's not actually hard to adapt to different styles in different projects. With formatter config files you don't even need to think about it.

[gnzlbg]

it just means people who don't like it can't use the standard formatting tool.

Just because you don't like the style doesn't mean you cannot use it.

I am not going to like the official style, and probably nobody will, because not a single person is going to decide the style, but it will be arrived at by consensus.

Still, even if users were able to customize the style, experience with clang-format (which is highly customizable) shows that they are still not going to like the result because the tool won't be magic (for example, it won't be able to infer that some macro declares a matrix or a tensor and needs to be formatted differently), it won't have all the options they want, and it will have bugs that will screw up formatting in some places.

So if "What if I don't like it" was a problem, allowing users to customize the style would not solve it. But I don't think it is a problem, I think it is a reality, since it has no solution.

As said above, I am not going to like the style that it is agreed upon, but I will still use it, and I am sure that after a week of using it I won't think about it again. Every programmer I know has been able to adapt to a different style when moving to a different project in a matter of days.

I am also sure that those who won't use the standard formatting tool will be a very tiny minority because the benefits of an automatic formatting tool is just too large.

There are basically no benefits to having a single global style, it's not actually hard to adapt

But then you still have to adapt. The benefit is no needing to adapt, ever, nor having to think about style ever again.

[Hrothen]

Just because you don't like the style doesn't mean you cannot use it.

Yeah, but it does mean that I won't use it for any of my own stuff.

I am also sure that those who won't use the standard formatting tool will be a very tiny minority because the benefits of an automatic formatting tool is just too large.

Many many people do not use formatting tools at all for any language, they are the vast majority.

[gnzlbg]

Yeah, but it does mean that I won't use it for any of my own stuff.

Of course, on that I agree, but chances are you will still use it.

For example, Haskell's hindent started supporting multiple styles, but this feature, originally implemented because its main author did not like the most widely used Haskell style (Johan Tibell's), has been removed in version 5 (blogpost, might be relevant to this discussion). Now it supports one single style only.

Many many people do not use formatting tools at all for any language, they are the vast majority.

This heavily depends on the language (e.g., see Go or C#), but I disagree, everybody inputs code as text at some point, and most programs for doing this have some level of code formatting support.