Line and indent width

[nrc]

Decide on the options and defaults for the maximum width of lines and indents.

Rustfmt currently has the following options:

    max_width: usize, 100, "Maximum width of each line";
    ideal_width: usize, 80, "Ideal width of each line";
    tab_spaces: usize, 4, "Number of spaces per tab";
    hard_tabs: bool, false, "Use tab characters for indentation, spaces for alignment";

The style guide specifies a maximum line width of 99 chars and 4 spaces (no tabs) for indentation. make tidy enforces 100 char width for the Rust repo.

Mostly these defaults seem reasonable. Points to discuss:

• 99 or 100 char width,
• 'ideal width' concept,
• which options should remain,
• names of options.

Notes:

• ideal width is not really used by rustfmt any more, in retrospect it was a bad idea. The only place it is used (I think) is for comments. I do think wrapping comments at 80 chars is nice, since reading prose is easier in narrower columns and the solid text of large comment blocks looks bad. It might be nice to keep the comment width at 80 and either remove the option to change it, or rename the option.
• the 99 chars thing is to cope with diffs in 100 chars or newlines in terminals.

[nrc]

On the indent width issue, some people prefer 2 spaces, but 4 is the most common in the eco-system. OTOH, 2 causes less rightward drift. Hard tabs are very uncommon.

[joshtriplett]

@nrc Personally, I'm a fan of the policy in the Linux kernel that suggests combating rightward drift by refactoring code, such as extracting functions or flipping conditions (e.g. if (error) { return ... } if (other_error) { return ... } rather than if (success) { if (other_success) { ... } }).

I also think 2-space indent doesn't provide sufficient visual differentiation of blocks.

So, I'd advocate 4 spaces.

[joshtriplett]

Reposting my comment from #2:

We need to define what to do in cases where wrapping at 100 must not happen. For example, taking inspiration from the coding style guidelines for the Linux kernel, I would advocate not breaking any string constant intended for printing to humans into multiple concatenated constants for word-wrapping; otherwise, someone searching for an error message in the code may not find it. (Wrapping immediately after a '\n' works, though.) Given this, though, rustfmt also shouldn't do silly things like wrapping a ; or ); immediately after the string constant onto another line.

Similarly, within a comment, a fixed-width block shouldn't get word-wrapped automatically. For instance, if someone puts a carefully formatted ASCII-art table or diagram into their comment, with a width of 120 characters, rustfmt should not mangle that. (It would presumably need to appear between triple-backquotes or similar.)

Finally, I think this needs associated reasonable procedures for where to break lines, how to indent continuation lines, and how to align those continuation lines. Those procedures might not need to appear within this RFC, but this RFC should acknowledge the need for them, and rustfmt shouldn't enforce wrapping (or un-wrapping) if it doesn't have a good way to handle alignment. (Simple example: whether to align operands of a binary operator, and whether to wrap before or after the operator. Another example: when wrapping a long if or while condition, where should the continuation line get indented to, and will it avoid potential confusion with the following body lines?)

[nikomatsakis]

Some comments from #2:

• @alexcrichton likes 80 spaces
• @wycats wanted 2-space indents
• @aturon is maybe interested in 2-space
• @nikomatsakis kinda likes 'em too, but worries about deeply nested expressions
• @wycats suggests we could address that more directly

[nrc]

Reminder to self (and others) to read the comments on #2 as well as the above summary

[Diggsey]

Two space indentation makes it difficult to see which lines are at the same indentation level when they're not very close together (Also this is why tabs are good, you get to choose an indentation level that suites you without modifying the code and thus avoid this entire argument, although it's a bit late to change to tabs...)

Overall I wish the style was exactly as described here: https://ubsan.github.io/style/

The stated goal of being "easy to manually format" is very far from being met with the current style, and visual indentation is horrible, both when writing and refactoring code, even if you're lucky enough to have an editor with support for it (I've never actually encountered an editor that handled this well, probably because of the inherent ambiguity in visual indentation...)

The way I see it, it's a trade off between being subjectively very slightly prettier in some cases (the current style) and being objectively simpler in all cases (ubsan's style). The latter has the distinct advantage of having almost no additional edge cases to consider, having no ambiguity so editors can easily do a good job of refactoring without having to reformat the entire file with an external tool, and a big one: eliminating unnecessary rightward drift!

[solson]

@ubsan's also expressed interest in 2-space indent in the past. Not sure why it didn't make it into that document - trying to be more status quo to reach more people, perhaps? I'd still like to find out what the community at large thinks about 2-space indent, after seeing arguments from both sides.

I haven't read that style guide in full but in the past I've mostly agreed with ubsan, especially regarding the style rules being simple and as free of edge cases as possible. I guess we should have another issue dedicated to visual indentation versus block indentation, and whatever else is important in ubsan's guide.

[joshtriplett]

I personally find 2-space indents much harder to read, because they make indentation levels less distinct.

(Also, some of the comments in #2 mention "2-space tabs". For the sake of clarification, I'd suggest talking about "2-space indentation" or similar, to avoid confusion with tab characters. We seem to have widespread consensus to avoid tab characters.)

[joshtriplett]

@Diggsey
I like the majority of those linked style guidelines. I have a few quibbles with some of the items about where to break lines, but most of those get superseded by the question of whether we should have a maximum line width at all.

The only item I found extremely problematic in those guidelines: the use of braces around if conditions and similar (as opposed to the body of the if). I find that quite confusing and visually ambiguous; it makes the condition look like the body.

[Diggsey]

@joshtriplett The guidelines say not to use extra braces around if conditions, etc.

[solson]

@Diggsey They contain examples with braces around if conditions.

EDIT: specifically in https://ubsan.github.io/style/#indenting

[nrc]

Could we try and keep this tread on-topic (the basic parameters - indent, width) please. I created #7 to discuss the general look and feel of code.

[joshtriplett]

@nrc Agreed. However, indentation and code width do interact very closely with where and how to break lines, so those topics will necessarily overlap.