This is the first I've heard complaints that Rust is too strict with formatting. If anything, the popularity of gofmt (which is far more opinionated than rustc's default warnings are!) is a testament to the fact that people want languages to be ruthlessly opinionated regarding style these days.

It's so much better to let the computer worry about formatting such that the programmer can worry about the logic.

fmt-tools offer the amazing possibility that one programmer writes and reads the same code with different formatting than another programmer. I'd love to be able to set my formatting in my editor so that I see it how it's best for me but on saving or sharing code the formatting is reverted to the standard.

So, I think there should be a default style for rustfmt, but also support for other styles.

rustfmt (currently in development) follows this principle.

Please don't make it an option. Use one format to rule them all, as with "gofmt". I don't care what it is, but pick something and standardize.

I'm not working on rustfmt but my understanding is that its output is going to be configurable.

Every language carries with it a culture. The culture of Go is one which allows for gofmt to define one true style and refuse to deviate, just as it allows the language designers to refrain from adding generics.

The culture of Rust is not like that, for several reasons. For one, the Rust community loves a good bikeshed. For two, the syntax of Rust is more complicated than Go, and includes situations (match statements & where clauses come to mind) in which people are just going to want to different things.

I know the advantages of one true style - everyone's heard the arguments - and there's a sane, median default as the official style guide, which will be rustfmt's default output. That seems like a good compromise.

It seems you are misunderstanding the situation because you are talking about not making “it” an option and you are then reiterating what I also said.

Even if I repeat myself: I think there should be one default formatting that is standardized and there should be the option to emit in other formats such that everyone can read in the individually preferred format.

With fmt you don't need to establish formatting rules on a project basis, anymore. Everybody can just configure their editor to format the code how they want it to look. That is why I think rustfmt should be compilable as a library, too.

That's absolutely OK and I do understand that people want that. I actually like snake case and only slightly prefer camel case. I'd write snake case in large open source projects, if it's actually preferred. But it's very awful to type snake case code on my keyboard and I'm not ready yet to switch to a US keyboard. The worst thing about that warning is that I get some kind of a bad conscience by disabling it.

Even on a US keyboard snake case is annoying to type (for me at least.)

have you thought about binding underscores to some other key combination at the operating system level?

SHIFT+SPACE could be a good keyboard shortcut for underscore because snake_case's underscores represent spaces between words.

Oooh, I hadn't thought about this. I might want to try this even on my (US) keyboard!

> If anything, the popularity of gofmt (which is far more opinionated than rustc's default warnings are!) is a testament to the fact that people want languages to be ruthlessly opinionated regarding style these days.

Its testament to the fact that there are some people that want that; that's very different from that being what people in general want.

I'm in the camp that would love for rustfmt to become both very strict/opinionated and widely used.

It makes everything so much easier to read.

The idea that "[u]sing a return as the last line of a function works, but is considered poor style" irks me so much. A lot of what I find appealing about Rust is that it makes so much explicit through its type system, so I don't understand the philosophy behind preferring implicit returns, especially since you could have a scenario where someone hasn't finished writing a function but it still compiles without error.

Implicit returns encourage functional style; foo.map(|x| x + 1) is so much nicer than foo.map(|x| { return x + 1; }). Once you have implicit returns in closures, you might as well have them everywhere for consistency.

I think that the "expression-style" return looks good for short and "expression-like" function.

Good

    fn inc(a: u32) -> u32 { a + 1 }
    fn foo(a: u32, b: u32) -> u32 { let x = a + b; a * x }

Bad

    fn bar(...) -> bool {
        let mut success = false;
        let conn = getConnection();
        ...
        if x > y {
            return false;
        } else if z < q {
            success = false;
        }
        foo.barify(x, y);
        ...
        success
    }

It looks especially bad when the function has multiple early returns, and then the final return looks different.

This could easily be added as a lint to the codebase.

Doesn't work when you're not returning from a function (ie, EVERY OTHER PLACE a block can appear)

Why "might as well"? Things can be optimal in some places and suboptimal elsewhere.

Consistency is valuable. If some blocks have different rules to other blocks that's a real downside.

That's true, but they're so syntactically different that I can't imagine a scenario where someone is asking whether it's closures or functions that you're supposed to use return statements in.

A foolish consistency is the hobgoblin of little minds. Sometimes a variation in rules allows for more clarity -- one could set their editor to make return a different color, for example, making it easier to glance at program flow. Then again, I'd argue that closures should allow returns too, like they do in C#. I'm an adamant supporter of the explicit camp -- when you have to debug things at 3 in the morning, sometimes that extra little bit of context can make things blindingly obvious.

I find the way it works in scala very nice - a block is just an expression that evaluates to the last statement in the block, and idiomatic code never uses "return" anywhere. Even e.g. a function definition, you can replace the block with a single expression if it's more convenient. I agree with being explicit but I don't think return actually makes things any more explicit (if you're talking about an editor highlighting, the editor knows which line is the value of the block, with or without a "return") - rather it's just syntactic ceremony. It's surprising how much difference having very low-overhead closures makes - you can make so much of your program simpler, because it's not a problem if a caller needs to make a slight modification to something.

Closures do allow returns in Rust.

> foo.map(|x| x + 1) is so much nicer than foo.map(|x| { return x + 1; })

"Nicer" is a subjective thing. BTW in the trivial case above one may judge this or that to be nicer, but in a large method, 'return func(a,b,c)' is obvious, whereas looking at 'func(a,b,c)' it is super non-obvious that the value is being returned.

It's not at all non-obvious if you learn the language. It's also not non-obvious if you learn any of the myriad other languages with the same semantics (including popular web languages like Ruby and CoffeeScript).

compromise. Make return very short, like a unary colon ":".

Then "foo.map(|x| :x+1)" is nice. If that doesn't stand out enough for some people on a line of its own, make your editor render the unary colon line in a very bold color for you.

That doesn't solve the fact that blocks and conditional control flow (if/else and match) are expressions and need a way to produce values.

The most compelling argument I've seen is that you don't explicitly `break` at the final run of a loop, either. An explicit `break` or `return` in the middle of a body can be thought as "abnormal" control flow. Otherwise, normal control flow will take place. As for a function, it would be returning the last expression.

That's what I mean. Why should I even care about stuff like this being "considered poor style" by the creators of Rust? "Poor style" is what doesn't work well for my team and me.

> Why should I even care about stuff like this being "considered poor style" by the creators of Rust?

Maybe you are writing code for the Rust standard library, where following the core projects style recommendations would be important for consistency.

Maybe you don't want to start from scratch coming up with your own style, and want a decent starting point from which you can vary as your team figures out what does/doesn't work for them.

Lots of reasons to have a language project also provide default style recommendations.

Style recommendations are great and if I was writing code for the standard library, I would certainly follow them. But they don't simply recommend their style. "We recommend doing this like that" is very different from "Doing this that way is considered poor style". That sounds like their recommendations were objective facts and you shouldn't do anything else, even if that worked better for you and the majority of other programmers.

> That sounds like their recommendations were objective facts

On the one hand, it is an objective fact that it is considered, by the authors, poor style.

On the other hand, that it is "considered" anything is an explicit (not merely implicit) statement that it is subjective (and "poor style" -- or good style, for that matter is inherently subjective in any case.) So, characterizing that language as making it sound "like their recommendations are objective facts" seems quite bizarre.

You can say that it can be an objective fact, though, that the majority of 'good developers' considers all that stuff poor style. Which is what I get from reading that book. If they don't intend to imply that, they should write it in a different way. The authors of various other books on various other programming languages are able to do that.

Yeah, that's one thing that's really putting me off looking at Rust - the possibility of it enforcing style in the future.

Hanging braces style for C/C++ is rarely allowed in the coding standards I've had to use in the past for embedded and real-time stuff in the defence industry, because it can be a source of errors.

Aligned opening and closing braces are much more common (in line with ADA's style).

Rust doesn't enforce style anywhere. You can turn off all style warnings at once too with `#![allow(bad_style)]` or a command line flag.

By default it just warns. That's not enforcing.

Come on, even that flag's name is ridiculous. They basically say, for example, that writing camel case, which is the preferred style in most of the projects I've seen, is bad style. Do they like being unnecessarily antipathetic? People think about their personal preferred style for years, and they have very good reasons for choosing them. And in _many_ cases, it's exactly the style that's called bad by Rust's creators.

How about making it the opposite, '#![allow(default_style)]'? Or at least '#![allow(non_default_style)]'?

In some cases skirting style can be harmful (e.g. in match statements there's an ambiguity with enum variants and variable bindings that is not an issue because of the style lints).

But I get your point. I think people would be open to that naming change if you file an issue.

Yes, you're right, of course.

Maybe I could at least try, yes. I mean... It's kind of silly, I know, but that would already change the way I look at Rust.

The compiler will not enforce more style in the future, that will be done by Rustfmt, a separate and optional tool. In fact, it is likely that the compiler lints which enforce style will move out of the compiler and in to Rustfmt at some point in the future.

I like the warnings about style and naming conventions. I kinda wish there were more of them. These warnings can help teams avoid arguments about things that don't really matter very much.

I think of the inforcing of style (snake_case CamelCase) is great, because it makes code more readable.