Rust-guidelines specifies whitespace

[brson]

Rust has always had a goal to set explicit language-wide style guidelines, and as @mitsuhiko points out one of the purposes of the document is to lay out those guidelines.

[cgaebel]

Is that an executive decision?

[gmorenz]

Even if it was supposed to be PEP8 for rust, I’d be against that, too. It is absolutely ridiculous that a language enforce (if rustfmt is commonly used to enforce spacing conventions, that is) both braces AND whitespace. Rust has already decided to be a braces-and-semicolons language. Don’t enforce whitespace rules or brace placement rules.

There is a difference between enforced rules, and recommended guidelines. If a project wants to ignore the guidelines and not use rustfmt, I don’t see anything stopping them.

[bfops]

Can rust-guidelines at least say something like “if a project’s style differs, opt to follow that instead when changing code”? I’m legitimately concerned about getting style that varies across a single project because it was started in a non-conformant way, and some committer later decided that following rust-guidelines was more important than following existing precedent.

[steveklabnik]

… then just reject that patch.

[bfops]

Like I said a while back, this moves bikeshedding into every repository that doesn't follow the style guide. I was hoping to get a "follow the pre-existing style" clause added to rust-guidelines to reduce that.

[tbu]

Like I said a while back, this moves bikeshedding into every repository that doesn’t follow the style guide. I was hoping to get a “follow the pre-existing style” clause added to rust-guidelines to reduce that.

That way project owners know that the official Rust style will be the path of least resistance, which is great for Rust the language, because more projects will have the official style.

[kaisellgren]

I am all in for a guide that defines whitespace rules.

I have written code in various languages and there are always syntactic differences between them and I am okay with that, but I really do not like syntactic differences between projects in the same language. There is barely any reason to have that.

[mkpankov]

I know of one example of language-wide coding style — it’s Python’s PEP-8. In my opinion, it’s incredibly helpful, especially to new programmers who don’t want to gather pieces of knowledge from unofficial sources and like an authoritative first-hand guide. It specifies a lot of things, including whitespace rules, and I see no problems in Rust style guide doing the same. In the end, if you know better, nobody actually prohibits you from doing what you want. But many people will “default” to standard, and it’s better situation than hundreds of styles to pick from, each with opposing arguments for specific points.

[steveklabnik]

Ruby effectively has a two-space indent style as well.

[c0g]

There most certainly should be whitespace and syntax rules. Beyond the many obvious advantages for comparing source it also precludes needless wasted time thinking about and arguing about things like where brackets should go.

Yes we’re all individuals and we’re all special and our opinions are magical. Who cares, let’s get some work done.

Follow Go’s example. It’s one of the things Russ and the gang got exactly right.

[cgaebel]

Yes we’re all individuals and we’re all special and our opinions are magical. Who cares, let’s get some work done.

Not everyone writes code for the sole purpose of all the time “getting some work done”. Sometimes programming is the nicest way to express an idea, and the result could be considered something closer to “art” than “engineering”.

By enforcing style conventions this way (and, I assume, with a rustfmt in the future), the idea of “artful code is a second class citizen to engineering code” is promoted.

[tshepang]

By enforcing style conventions this way (and, I assume, with a rustfmt in the future), the idea of “artful code is a second class citizen to engineering code” is promoted.

“enforce” is a strong word; “recommend” is more accurate

[mkpankov]

By enforcing style conventions this way (and, I assume, with a rustfmt in the future), the idea of “artful code is a second class citizen to engineering code” is promoted.

Could you please enlighten us, what will stop you (or any other developer potentially wanting to format their code differently) from styling the program as one would like? Even while there’s some “Standard Rust”. I actually hope we could standardize the thing at some point in future; not in terms of formatting, but in terms of language specification. There always will be custom formatters and dozens of editors, each of which implements styling so-slightly-differently, so what’s the problem about?..

[iopq]

I really like elastic tab stops.

Agreeing to 4 spaces per tab would be weird because elastic tab stops work with tabs, not spaces.

[mkpankov]

If you’re referring to http://nickgravgaard.com/elastictabstops/, I think it has not enough adoption to even consider this point.

Overall: this is what you achieve pretty easily using good editor with rectange selection or multiple cursors (meaning Emacs or Sublime Text) when spaces are used for indentation and alignment.

[iopq]

Well I like it and I use it. It allows me to indent everything vertically without having to line everything up manually. It also allows me to use a proportional font and I don’t have to realign everything manually.

If Rust has guidelines for spaces instead of tabs, then I can’t use this feature in my contributions to the Rust ecosystem. But if anything, the practice agreed on should be the best practice, not the most popular. If the Rust IDE has automatic elastic tab stops, then I would prefer this to be the default. If not, I don’t see how forcing me to use spaces is a good thing.

[comex]

If you want people to be able to read and modify your code effectively, you can’t format it in a way the editors most people are using will render wrong; if you don’t care, you can do what you want. Either way, it doesn’t really matter what any document says. A canonical Rust IDE could increase adoption, but currently no such thing has even been started, let alone become good enough to supplant people’s favorite editors.

[iopq]

It will only render it wrong from vertical alignment standpoint. That means people can read it fine, it just won’t be lined up. If spaces are the standard, not tabs, people will consider me a heathen and I won’t be able to publish my code publicly at all.

[mkpankov]

It will only render it wrong from vertical alignment standpoint. That means people can read it fine, it just won’t be lined up.

Reading non-aligned (or wrongly aligned) text is actually a lot of pain. Just going from tab width of 4 to tab width of 8 will violate width restriction (< 100 chars) for deeply nested blocks, so you won’t see any code w/o horizontal scrolling. Speaking of width restriction - it only makes sense in conjuction with total specification of indentation width. And it’s pretty much impossible w/o making indents with spaces.