Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Create a rustfmt.toml definition #456

Closed
vlopes11 opened this issue Oct 27, 2022 · 6 comments
Closed

Create a rustfmt.toml definition #456

vlopes11 opened this issue Oct 27, 2022 · 6 comments

Comments

@vlopes11
Copy link
Contributor

Consider standardizing the rustfmt definitions so we have a consistent style across the project

This will also halt the CI when there is something out of style so we automatize this review

Originally posted by @bobbinth in #450 (comment)

@bobbinth
Copy link
Contributor

If we will be defining out own rustfmt rules, maybe we could also consider setting the following parameters:

array_width = 80
attr_fn_like_width = 80
chain_width = 80
fn_call_width = 80
single_line_if_else_max_width = 60

@grjte
Copy link
Contributor

grjte commented Nov 8, 2022

I think this is a good idea. I'm fine with all of the parameters suggested by @bobbinth, since the style of the codebase was set by his initial work anyway. I guess the main downside with straying from the defaults is that people will get more failures when opening PRs, including new contributors

We could also consider turning on doc comment formatting.

format_code_in_doc_comments = true

This would also enforce the max width of 100 that we use. It's currently unstable, but that's because it panics on empty code blocks in comments (rust-lang/rustfmt#5234)

@vlopes11
Copy link
Contributor Author

My suggestions are

max_width
value: 110
modern IDEs are bigger than the classic 80-100 cols

condense_wildcard_suffixes
value: true
tracking issue: #3384
we save chars on unused tuples

enum_discrim_align_threshold
value: 40
tracking issue: #3372
enum discriminants are more readable if aligned

fn_single_line
value: true
tracking issue: #3358
we save many lines of code from expressions that are of no relevance

format_code_in_doc_comments
value: true
tracking issue: #3348
everything must be formatted, including examples

format_macro_matchers
value: true
tracking issue: #3354
ditto; everything must be formatted

format_strings
value: true
tracking issue: #3353
We end up having to do that manually for MASM strings

hex_literal_case
value: lower
tracking issue: #5081
better to have a standard, and lowercase = less keypress

imports_granularity
value: "Crate"
tracking issue: #4991
We are enforcing the crate style manually; better delegate this to rustfmt

newline_style
value: "Unix"
Because Microsoft should never have created a new standard anyway

normalize_doc_attributes
value: true
tracking issue: #3351
Kinda old style that no one uses today, but better enforce that via rustfmt so no old school Rustacean external collaborator will introduce that.

reorder_impl_items
value: true
tracking issue: #3363
Quite important to keep this type of consistency. IMO should be a default value in rustfmt

group_imports
value: "StdExternalCrate"
tracking issue: #5083
Easier to find dependencies if we always have the same order of imports, everywhere.

tab_spaces
value: 2
I think 4 is a waste of precious columns

use_field_init_shorthand
value: true
less code, same effect

use_try_shorthand
value: true
ditto; will be useful if some old school contributes

wrap_comments
value: true
tracking issue: #3347
comments should also follow format rules

@bobbinth
Copy link
Contributor

bobbinth commented Dec 1, 2022

Thank you! Agree with pretty much everything. The only two exceptions it that I would keep the following settings as follows:

  • max_width = 100
  • tab_spaces = 4

@vlopes11
Copy link
Contributor Author

vlopes11 commented Dec 2, 2022

@bobbinth sounds good! The change is simple in nature but will break all ongoing PRs since it will cause merge conflicts everywhere. Should we do it now or wait for the conclusion of 0.4?

@bobbinth
Copy link
Contributor

Closed by #594

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants