Column limits and rightward drift

[cmr]

Lines must not exceed 99 characters.

Why 99, and not 100, or some other arbitrary number?

Use 4 spaces for indentation, not tabs.

These two rules combined with pattern matching conspire to make me squeeze a lot of code into less than 80 columns. You get a level of indentation from the impl, method, and then the match, already 12 columns gone! And then you add any loops or conditions, and you’ve wasted 20+ columns on whitespace.

We used to use 3 (2?) space indents and I personally prefer that. In OCaml, they use 2 space indents, and often don’t indent some constructs. Our syntactic heritage causes many of the same problems that motivated those decisions. On the other hand, F# (also an ML) uses recommendations much like ours, but without the line length limit.

[aturon]

re: the 99 rather than 100 limit, see https://github.com/rust-lang/rust-guidelines/pull/12

[retep998]

Personally I find that 99 columns is the perfect size to let me have 2 panes of code side by side on my 1080p monitor. I also like to keep my console at a width of 100 (and in all consoles I’ve used a newline itself takes up space so a 100 wide line causes an extra blank line). As a point of reference, Github usually displays 120 wide for me.

[o11c]

All the terminals I’ve used display 80 columns followed by a newline just fine - I’m pretty sure it’s required by the testsuite. But 79 is very useful for another reason: diffs.

Personally, I use 75 so I have room for column numbers in vim …

I don’t really understand the arguments for going higher than 80 … if you have too many levels of indentation, refactor something into a separate function; if you have too many chained calls, add some temporary variables or at least break before the ..

Remember that the linux kernel uses the 80-character limit with 8-space indents!

[cmr]

Linux also has a “if you have more than 3 levels of indentation you’re doing it wrong” policy. But, with 75 columns I can fit 5 editor windows side-by-side on my screen! I don’t care what we use. Ideally we’d use nothing, and editrs would be smart enough to reflow correctly. But that future never comes.

[steveklabnik]

Ruby uses two space indents and I love it, but four is okay.

[riccieri]

In my own code, I’ve found that the four space indentation + Rust’s tendency to get nested forces me to use smaller variable and method names, just to avoid breaking up the line in weird places. I don’t know if that is a problem, but is certainly different from what I’m used to do - using long, descriptive names (within reason) as substitute for inline comments

[Arcterus]

My personal preference for indentation is three spaces, so I would love it if we used that.

[nathantypanski]

While I agree that 80 character wide windows play better with 79 column wraps in general, this post quotes Guido on the matter:

Because an 80 char wide Emacs window starts wrapping at 79.

But I agree that in general it’s hard to write Rust code that doesn’t contain a sea of nested blocks.

[ecl3ctic]

I was using 3-space indents before I first acknowledged the “official Rust style”. FWIW I much prefer that. Rust code tends to have a fair amount of indentation, and with 4-space indents you can soon end up with 50 or less characters of usable room. Then you start spreading out simple statements over several lines and the end result is usually far less readable code.

[DanielKeep]

For what it’s worth, I think the line length limit should either be 79 (since there are technical justifications for it), or none at all.  If you start going based on arguments like “well, it lets me fit two editors on screen”, someone with a different editor will disagree.  The person with triple monitors will want 120.  The poor bastard whose second monitor went kaput and has to make do with just one will want 76 (1).

What’s more, if you pick 99, then anyone who wants to use a window that only fits 79 will either have to scroll horizontally to read other’s code (which I can’t recall ever working properly with my mouse in anything except Excel, and even then it’s stupid), or code will soft-wrap in really ugly places.  If they’re anything like me, they’ll just ignore the style guide on this, because it’s easier to do that than buy a new monitor or switch editors.

As for indents, I like 4; 2 is too little, 8 too much, and 3 is an evil non-power of two number and all who use it are heathens who should be burned at the stake! (2)

---

(1): It lets me fit an editor at a decent font size on the right, with a browser for reference on the left.  Even then, a lot of reference sites need horizontal scrolling, but oh well.

(2): I dream of an editor that, aside from being able to re-flow code in a half-way intelligent manner, also treats tabs flexibly. As you indent further, it makes the outer tab layers thinner and thinner, as well as shifting the view to the right when there’s nothing but empty space on the left. sigh

[SealedSun]

I think 99 characters and four spaces is fine.

I would not go below 99 characters, however. I find 80 characters very narrow.

Personally, I would prefer an indentation of just 2 spaces. With modern editors drawing vertical lines for each level of indentation, I’ve never had trouble “seeing” differences in indentation with just 2 spaces.

[iopq]

This line of code is 80 characters:

[_, ref n, ..] => from_str::<int>(n.as_slice()).expect("I need a real number"),

and since it has to be inside of a function AND a match statement it won’t fit into 80 character limit.

For me it’s important that the line MINUS whitespace is 80 characters. Because I can live with 3 way merging something indented where I can see all of the code and have to just scroll a little to the side. An actual 80 character limit means I’d have to break many lines at awkward places even while writing FizzBuzz.

[steveklabnik]

You can make that line take up less space (and arguably make it more clear) with

[_, ref n, ..] => from_str::<int>(n.as_slice())
                          .expect("I need a real number"),

Ugh, the code formatting looks ugly, but you get the idea.

[bstrie]

Why 99, and not 100, or some other arbitrary number?

It’s not arbitrary. When this limit was chosen, we did a survey of popular websites that are used to share code (Github, Gist, SO, Reddit, etc.). 100 was chosen as the longest length that will fit without wrapping or scrolling on all of these sites, given standard font size, standard system fonts, and the most common browser widths.

You may find this to be a flimsy justification, but Graydon was adamant on enforcing line widths, and everyone else was fed up with the low limit of 78.

We used to use 3 (2?) space indents

This is incorrect. We used to use two space indents only within match arms, and even then it was only ever adhered to by emacs users because our vim plugin was not sophisticated enough (I’m not sure how hard it would be to make vim support this sort of syntactic context analysis). Good times were had guessing a developer’s editor of choice via git blame.

FWIW, I wouldn’t be opposed to two-space indents across the board (but it’s not that important to me). But let’s not go back to the editor-specific hell that was the old system.

[cmr]

But let’s not go back to the editor-specific hell that was the old system.

Certainly, consistency is definitely king for style.

[bstrie]

I’d like to also point out that abolishing line length restrictions basically solves the hardest problem of pretty-printing. A proper rustfmt would be much more likely to emerge. However, whether or not that is worth the cost is up for debate. Go gets along fine without official line length restrictions, but Rust lines seem to be generally longer than Go lines.

[jimuazu]

Has anyone studied the gofmt algorithms? They seem to maintain line feeds in some places but not others. So linebreaking is still under the control of the programmer to some extent. (Just trying it, if I put a linebreak in a for, it is removed, but if I put it after = in an expression, it is maintained. Putting a linebreak before a dot (as above) doesn’t work because that messes up the algorithm for implied semicolons.)

[eridius]

99 is exceedingly arbitrary. 100 is at least a nice round number, but the only justification for 99 is a misapplication of the justification for 79 vs 80. In that case, if you’re treating 80-column terminals as special, 79 makes some sense as there are apparently terminals or editors (e.g. Emacs) that will wrap the 80th char in an 80-column terminal. But once you’ve chosen to ignore the historical legacy of 80-column terminals, then the same argument doesn’t work for anything else. There’s no special nature to a 100-column terminal that justifies a line length of 99.

I believe that we should have some line length limit, because code typically doesn’t do great in a soft-wrapped environment, and horizontal scrolling should be avoided when possible. And 80 is definitely too short. 100 is doable, but even that sometimes feels just slightly too short. My personal preference is for 120. But 100 is a reasonable alternative.

But 99? That just doesn’t make sense.

It’s not arbitrary. When this limit was chosen, we did a survey of popular websites that are used to share code (Github, Gist, SO, Reddit, etc.). 100 was chosen as the longest length that will fit without wrapping or scrolling on all of these sites, given standard font size, standard system fonts, and the most common browser widths.

So why not use 100?

My personal preference for indentation is three spaces, so I would love it if we used that.

Is this a thing? I’ve never heard of anyone using 3-space indents until this thread, and there are multiple references to it here.

[Arcterus]

Is this a thing? I’ve never heard of anyone using 3-space indents until this thread, and there are multiple references to it here.

Yeah, I’ve been using 3-space indents for a couple years now. IMO, it’s the perfect size as it is smaller than 4-space indents (which I think are too large), and larger than 2-space indents (which I think are too small). I’m not really sure why more people don’t use it, other than it not being a power of two.