Announcing the code style RFC process and style team


#1

I’m happy to announce the beginning of the code style RFC process. The goal of the process is to configure Rustfmt and provide guidelines for the default code style when programming in Rust.

The style team is a strike team (a sub-team with a very specific focus and limited duration, in this case one year) formed to administer and lead the code style RFC process. The members of the team are:

  • Brian Anderson (@brson)
  • Jorge Aparicio (@japaric)
  • Nick Cameron (@nrc, team leader)
  • Steve Klabnik (@steveklabnik)
  • Nicole Mazzuca (@ubsan)
  • Scott Olson (@solson)
  • Josh Triplett (@JoshTriplett)

The code style RFC process is based on the existing Rust RFC process, with some small changes. To summarise:

  • File an issue to discuss a code style topic. Generally, smaller is better.
  • Reach rough consensus on the issue.
  • Implement the consensus in Rustfmt as an option (or multiple options if there is a set of candidates).
  • File an RFC PR using the RFC template.
  • Reach final consensus on the PR, with the benefit of being able to automatically format code.
  • Final comment period (FCP).
  • Accept the RFC and make the Rustfmt option the default (and possibly remove other options, exactly how this works is still to be decided (by RFC)).

For more details, see the code style process RFC.

Like most things in Rust, we want as much community participation as possible. We therefore invite you to be involved in discussion, filing issues, and submitting RFC PRs. These should all be done on the fmt-rfcs repo. For synchronous discussion, please join the #rust-style irc channel. Or for heavier-weight, async discussion, you can use the style and formatting category on internals.r-l.o.


#2

configure Rustfmt and provide guidelines for the default code style

Does this mean that non-default styles are out of scope? Does one first need to make an argument that a particular style should be the default in order for it to be considered in scope?


#3

If you want to add a non-default style to Rustfmt, you can just send a PR. However, in the longer run, we might restrict the number of non-default options or make them harder to access (see https://github.com/rust-lang-nursery/fmt-rfcs/issues/3). We also need to rationalise the non-default options, which may either fall to the Rustfmt implementers or to the style team, depending what is decided in the linked issue.