6 ms·
I'd like Rust to be shipped without counterintuitive standard library function names and that book with all its style 'recommendations'. And I'd like the Rust c
by andresmanz 11y ago
I'd like Rust to be shipped without counterintuitive standard library function names and that book with all its style 'recommendations'. And I'd like the Rust compiler to be shipped without that non-snake case warning enabled by default.
Language creators won't endear themselves to me by ranting. The problem I have with Rust is _not_ the language itself.
- ericsink 11y agoI 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.
- berkut 11y agoYeah, 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).
- nrc 11y agoThe 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.
- Manishearth 11y agoRust 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.
- andresmanz 11y agoCome 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)]'?
- Manishearth 11y agoIn 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.
- andresmanz 11y agoYes, 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.
- pcwalton 11y agoThis 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.
- andresmanz 11y agoThat'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.
- jpgvm 11y agoI'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.
- deleted 11y ago[deleted]
- 88e282102ae2e5b 11y agoThe 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.
- pcwalton 11y agoImplicit 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.
- veddan 11y agoI 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.
- Eerie 11y agoSheesh, it's such a little thing. "success" vs "return success;"
- cmrx64 11y agoDoesn't work when you're not returning from a function (ie, EVERY OTHER PLACE a block can appear)
- ewillbefull 11y ago
- gbersac 11y agoI think of the inforcing of style (snake_case CamelCase) is great, because it makes code more readable.