Skip to content

Commit 66da09f

Browse files
committed
Added RFC for style checking with rustfmt
1 parent c329d69 commit 66da09f

File tree

1 file changed

+34
-0
lines changed

1 file changed

+34
-0
lines changed

rfcs/0207-rustfmt-our-libs.md

Lines changed: 34 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,34 @@
1+
# Summary
2+
[summary]: #summary
3+
4+
This RFC proposes to use CI to give errors, or bors to apply rustfmt on merge to
5+
make sure our lib do not diverge in style within the WG's libraries. Moreover,
6+
it can act as a reference for newcomers to also follow the same style.
7+
8+
# Motivation
9+
[motivation]: #motivation
10+
11+
The main motivation is to keep the WG's style consistent. As libraries continue
12+
to evolve over time, as will the style if we do not have a system to keep us in
13+
check. It could also be used as an example to motivate the newcomers of embedded
14+
Rust to use `rustfmt` and keep the style consistent. It helps everyone when
15+
opening someones code and feeling at home, and not needing to reread the code to
16+
understand the style of the writer, which is a common issue in for example C++.
17+
18+
# Detailed design
19+
[design]: #detailed-design
20+
21+
All in all, two main methods were discussed:
22+
23+
1. Enforce `rustfmt` at CI level, and have an extra target for formating which
24+
will fail if the code is not following the correct style. This does however mean
25+
that there can be a lot of commit noise to just "fix CI style errors".
26+
27+
2. Have bors apply rustfmt on merge. This would be the painless method, but
28+
would not act as an example for newcomers.
29+
30+
# Unresolved Questions
31+
[unresolved]: #unresolved
32+
33+
* Should we do it?
34+
* If so, which method to use?

0 commit comments

Comments
 (0)