Official Rust Style Guide

internals bikeshed (deprecated)
1

So I’ve been putting some work into pcwalton/rustfmt and feel like it’s in a place, especially after #15339 lands, where we can get the pretty printer component (the only component, atm) into great shape and have it be suitable for public consumption.

The issue is that, beyond “four spaces, no tabs” and naming conventions, there isn’t much in the way of official rust style guidence.

There’s a lot of stuff to cover, like:

  • when newlines are approp.
  • is 100 chars a hard and fast limit (this is something that could be supported into a [heavily refactored] formatter w/ backtracking)?
  • collapsing parens for empty match arms (something I’ve already added that isn’t in a style guide)… should we also collapse empty function blocks?
  • should we transform identifiers that don’t conform to the naming conventions?
  • we have lints for needless parens, but should we put this in the style guide?
  • etc, etc

There’s a lot of stuff out there. Much of it is held in the heads of people who write lots of rust and/or have spent enough time in the stdlib to know conventions. There’s a lot of things that aren’t in Notes: Style Guide…

So I guess my question: Should we draft an official style guide as part of the docs? What should go in? What should be left out? I’m not sure where to initiate this conversation or how the styleguide should be created and maintained. Would be great of some stakeholder would be willing to make a proclamation on this.

An obvious source of inspiration/scope would be Google’s C++ style guide at https://google-styleguide.googlecode.com/svn/trunk/cppguide.xml . Please feel free to share other style-guides that you think would be germaine to this discussion.

(Also any discussion about the eventual scope of a feature-complete rustfmt should be swell)

2

aturon’s been working on a style guide here that you may be interested in.

1 Like
3

Maybe PEP 8 could also be considered.

For example, the keyword parameter rule could be used for attributes, i.e. the more compact

#![crate_type="rlib"]

instead of

#![crate_type = "rlib"].

Or, as opposed in the google style guide, allow the bracket style

function_with_long_name_and_many_parameters(
    foo_foo_foo_foo_foo,
    bar_bar_bar_bar_bar,
)

similar to the {} style.

4

An official Rust Guidelines project has now been announced!

We’ll be using the discuss.rust-lang.org forum as the primary arena for guideline discussion.

5

The Perl Critic module based on Perl Best Practices may be worth taking a look at.

6

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.