Rust-guidelines specifies whitespace

[cgaebel]

I don’t think rust-guidelines should specify whitespace, and propose that rule is removed.

It is my understanding that the rust-guidelines project should be used to guide API design. Whitespace is not a part of API design, therefore should not be specified. This has the additional advantage of avoiding the largest bikeshed ever to grace the PL community.

[tbu]

Go does it successfully.

[cgaebel]

Go does not have a document called “go-guidelines” which is used to specify API design guidelines. So no, they do not do “it” successfully.

[mitsuhiko]

The guidelines go beyond api. It’s a good idea that they define whitespace because that way it defines a strong recommendation.

Whitespace is important because of diffs.

[cgaebel]

A consistent whitespace convention per-project is important because diffs. However, there’s no need to create a far-reaching every-project convention.

I am also arguing that the guidelines should NOT go beyond API.

[steveklabnik]

There is a need for far-reaching convention. Many people work on many different codebases.

[bfops]

I have rarely, if ever, encountered a coder who is not willing to conform to a new project’s style conventions when making changes, especially with something as obvious as whitespace. I absolutely agree that this is a massive bikeshed brewing, as are similar syntactic “guidelines” like brace positioning. The main reason I can see for having far-reaching guidelines is to make copy-pasting code across projects easier.

[Gankro]

It also allows for rustfmt to be created.

[cgaebel]

rustfmt is not blocked on a globally-fixed indent width. If it doesn’t stop ocp-indent, it has no reason to stop rustfmt.

But that’s beside the point. My point is that it is not an API convention, so should not be in the document that lists “rust API conventions”.

[gmorenz]

Sorry, this discussion is referring to this document right?

If so, why are you only objection to whitespace when a large portion of the document is not API conventions?

Specifically the sections

• Whitespace
• Braces, semicolons…
• Imports
• Let Binding
• Pattern Matching
• Loops

don’t seem to have anything to do with API conventions.

[cgaebel]

That’s actually a great point. Whitespace was just the first thing I noticed. None of these have a place in an API conventions document.

[mitsuhiko]

That’s because it’s not an API conventions document.

[cgaebel]

https://mail.mozilla.org/pipermail/rust-dev/2014-July/010735.html

One of the key steps in that direction is reaching firm decisions on a number of API design questions, ranging from bikesheddy stuff like naming conventions to meatier stuff like when and how to use traits for overloading.

It makes sense to stabilize API conventions for 1.0. It makes less sense to stabilize style conventions.

[mitsuhiko]

What I read out of this is that you’re not satisfied with the whitespace rules?

[cgaebel]

I am not satisfied that there exists globally-enforced whitespace rules in a document that claims to be about API conventions.

[bfops]

I personally disagree with the whitespace rules, and a few of the other syntactic guidelines, but I’m also unhappy with the presence of rules I agree with, like brace positioning. “Correct” formatting is an inherently subjective thing and there’s no optimum we can get to just by discussing enough. There are plenty of intelligent people who simply differ in their opinion of what the “best” formatting for a given piece of code is, and there’s no reason the codify the opinion of one and not the other. It invites bikeshedding in every place where somebody has made a decision to break the formatting guidelines.

[mitsuhiko]

“This document collects the emerging principles, conventions, abstractions, and best practices for writing Rust code.”

Where does it claim to be about API conventions? It s not. It’s the Rust equivalent to PEP 8.

Exactly because formatting is subjective there needs to be a standard for it. Otherwise this discussion never ends.

[bfops]

My point is that when there’s a valid difference of opinion, “pick an arbitrary side to be globally considered correct” doesn’t seem like a positive resolution.

What’s wrong with the formatting guideline being “follow what the project already does”?

[cgaebel]

I already quoted the relevant section in my last post:

One of the key steps in that direction is reaching firm decisions on a number of API design questions […snip]

The mail does not claim the document is meant to be PEP8. It merely specifies API conventions to have a uniform API across libraries for 1.0.

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.

[mitsuhiko]

What’s wrong with the formatting guideline being “follow what the project already does”?

Rust is a new programming language as such it has no legacy code and can set guidelines