Skip to content

Commit 713d8e9

Browse files
committed
Define the maximum width of a line and the width of indentation.
Closes #1
1 parent 5fecdf9 commit 713d8e9

File tree

1 file changed

+128
-0
lines changed

1 file changed

+128
-0
lines changed

text/0000-line-width.md

Lines changed: 128 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,128 @@
1+
- Start Date: 2016-05-04
2+
- RFC PR: (leave this empty)
3+
- Implementation Issue: (leave this empty)
4+
5+
# Summary
6+
[summary]: #summary
7+
8+
Define the maximum width of a line and the width of indentation.
9+
10+
11+
# Details
12+
[details]: #details
13+
14+
The maximum width of a line is 100 characters. The maximum width of a comment
15+
(including any commenting characters, e.g., `//`, but not including any
16+
indentation) is 80 characters. A comment should be wrapped at the minimum of the
17+
80 character comment limit and the 100 character line limit.
18+
19+
Indentation should use spaces, not tabs. Each level of indentation should be
20+
four characters wide.
21+
22+
Empty lines should have no whitespace, even if lines above and below are
23+
indented.
24+
25+
Example:
26+
27+
```
28+
// Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod
29+
// tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam,
30+
// quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo
31+
// consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse
32+
// cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non
33+
// proident, sunt in culpa qui officia deserunt mollit anim id est laborum.
34+
mod foo {
35+
mod bar {
36+
// Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod
37+
// tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam,
38+
// quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo
39+
// consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse
40+
// cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non
41+
// proident, sunt in culpa qui officia deserunt mollit anim id est laborum.
42+
fn baz() {
43+
this_is_a_very_long_function_name_and_the_line_is_long(1 + 2 + 3 + 4 + 5 + 6 + (7 + 8));
44+
}
45+
46+
// Note, the above line is empty, no indentation.
47+
fn qux() {
48+
}
49+
}
50+
}
51+
52+
fn main() {
53+
println!("Hello, world!");
54+
}
55+
```
56+
57+
58+
# Implementation
59+
[implementation]: #implementation
60+
61+
Rustfmt options:
62+
63+
* `max_width` remains defaulted to `100`.
64+
* `ideal_width` is removed.
65+
* A new option, `comment_width`, is added with value `80` and type `usize`.
66+
* `tab_spaces` is renamed to `indent_width` and remains `4`.
67+
* `hard_tabs` remains `false`.
68+
69+
All these options remain configurable. A `comment_width` of 0 means that Rustfmt
70+
will not take into account a maximum comment width and will only be constrained
71+
by the line width.
72+
73+
The only implementation work required is the change from having an `ideal_width`
74+
(which only applies to comments) to `comment_width`. The change is that
75+
`ideal_width` was a line width, including indentation, whereas `comment_width`
76+
is not.
77+
78+
[Note: this level of implementation is something of a grey area - the change is
79+
a tweak to an existing option, but is bordering on a big enough change to
80+
warrant implementation before the RFC is submitted. The reality is that at the
81+
moment comment formatting in Rustfmt is pretty bad and so implementation is a
82+
bit irrelevant. I hope by the time the fmt-rfcs repository is live and the
83+
formal process starts for this PR, comments are in a better state and this
84+
implementation work will be done].
85+
86+
87+
# Rationale
88+
[rationale]: #rationale
89+
90+
Common choices for line width are 80 and 100 characters. Restricting to 100
91+
(rather than a larger number) is good for users with older hardware, reading
92+
code on mobile devices, using terminals, and having two files side-by-side on a
93+
wide screen.
94+
95+
Indentation is commonly two or four spaces. Four seems to be more popular in the
96+
Rust community and is used in the Rust project itself (and pretty much every
97+
other project).
98+
99+
Due to four-space indent and Rust's 'culture' of rightward drift, 100 spaces is
100+
more appropriate than 80. It is widely used (Rust, Servo, most other projects).
101+
102+
Comment lines are usually prose rather than code, therefore there are different
103+
pressures. [Studies](http://baymard.com/blog/line-length-readability)
104+
have shown that wider lines of text are harder to read. Especially for long
105+
comments (e.g., documentation at the head of modules), 100 character-wide text
106+
feels extremely 'heavy'. This de facto limit is adhered to by most of the Rust
107+
project (e.g., [libstd](https://github.com/rust-lang/rust/blob/master/src/libstd/lib.rs)).
108+
109+
110+
# Alternatives
111+
[alternatives]: #alternatives
112+
113+
The style guide currently recommends 99 character wide lines. This allows for
114+
diffs to be 100 characters wide. However, this rule is not followed in practice
115+
by the Rust project (where `make tidy` enforces a 100 character limit).
116+
117+
We could limit the width of comment lines to 80 characters including
118+
indentation. This is probably easier to format manually (text editors usually
119+
have a line wrap function which does this). However, it means deeply indented
120+
comments end up very narrow.
121+
122+
Rustfmt could be made significantly simpler by removing the `hard_tabs` option.
123+
However, it is a popular alternative, so should probably be left as an option.
124+
125+
# Unresolved questions
126+
[unresolved]: #unresolved-questions
127+
128+
None.

0 commit comments

Comments
 (0)