-
Notifications
You must be signed in to change notification settings - Fork 8
Update recommended rustfmt config #96
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
base: main
Are you sure you want to change the base?
Conversation
(I swear there was a discussion somewhere on why we didn't want to use |
Found it. |
# Ensure lines end with \n even if the git configuration core.autocrlf is not set to true | ||
newline_style = "Unix" | ||
|
||
# `Foobar { foo, bar }` is more readable than `Foo { foo: foo, bar: bar }` | ||
use_field_init_shorthand = true | ||
|
||
# Forces let else blocks to always be their own line(s). | ||
# Enforcing this helps readers scan all early returns of a function at a glance. | ||
single_line_let_else_max_width = 0 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Copying my previous review comment from the last time you submitted this:
If we do decide to set this, I'd expect it to have the same value as
single_line_if_else_max_width
, I think.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I disagree, for the reason exposed in the comment above.
I think
let foo = if x { y } else { z };
is fundamentally different from
let Some(foo) = x { y } else { return z };
and that, unlike the if else
case, the else return
case deserves to be spread out no matter its length.
In general, I think a control-flow-altering statement should always be on its own line.
(In theory you can do a single line if x { y } else { return z }
, but only by treating the return statement as an expression, which is rare in practice.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for providing reasoning. I'm not completely sure I agree; for one thing, no style guide would ever have the formatting:
some_fallible_operation()
?
.action()
?;
To be clear, my preference would just be to stick with the default, rather than matching the two at zero; I don't think it's a significant enough win, and IDEs can already highlight exit points for you in a much more complete manner
That being said, I'm not going to argue for it further; e.g. the Xilem repository which already has this set has literally no occurrences which would be formatted on a single line anyway.
content/wiki/formatting_scheme.md
Outdated
# Commented out because it is still unstable, but works fine in practice. | ||
# imports_granularity = "Module" | ||
|
||
# END LINEBENDER RUSTFMT CONFIG | ||
``` | ||
|
||
You may also want to occasionnally use this unstable config: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
s/occasionnally/occasionally/
(too many n
s)
Can you submit this misspelling to typos?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done.
group_imports = "StdExternalCrate" | ||
``` | ||
|
||
We don't recommend it as a permanent config value even for nightly projects, because the way it reorders items [isn't always ideal](https://github.com/linebender/linebender.github.io/issues/87). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe "exports" rather than "items" here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think "items" is fine for a short description.
I don't see why we need to customize this at all. |
No description provided.