Add alias 'nonstandard_style' for 'bad_style'

[Manishearth]

@ashleygwilliams mentioned this in her talk today; #[allow(bad_style)] is a rather rebuke-y shame-y annotation on code.

While we do want people to use proper style, it's a useful tool whilst learning to be able to turn off all the extra friction that you deal with that you don't have to. Let's be nicer about it; could we rename this to nonstandard_style and keep bad_style as a backcompat alias?

Unsure if this requires an RFC.

[Manishearth]

(Actual name of alias very bikesheddable, I just picked the first thing that came to mind.)

[skade]

Bikeshed: "relaxed_style" sounds good.

[leonardo-m]

"bad_style" sounds better than "nonstandard_style" because "nonstandard" sounds un-opinionated. The point of a "bad_style" annotation is to help people feel guilty.

[Manishearth]

Right, I'm questioning if that's a good thing. Do we need to? Even nonstandard_style (or in general, any warning-allow) does make you feel guilty, bad_style is just very much like a shaming and feels bad.

[mgattozzi]

Her talk was great. I think using something like relaxed_style or permissive_style would be a better choice then bad_style

[tumdum]

I think that 'any_style' is short and is not passive aggressive at all :)

[steveklabnik]

marking as both @rust-lang/compiler and @rust-lang/lang ; not sure who this falls under, really. Also nominating for discussion; I'm not sure if this requires an RFC or not.

[retep998]

As one of the heaviest users of bad_style (https://github.com/retep998/winapi-rs/blob/dev/src/lib.rs#L9), I'd like to voice my lack of opinion on this matter.

[ashleygwilliams]

i have no opinion on what we alias it as, but i would be very interested in an alias that is less shame-y. i am also very happy to implement once we decide what a good alias is!

[nikomatsakis]

For those readers who (like me) were not familiar with the bad_style group, it refers to a collection of 3 lints that enforce various capitalization conventions (e.g., snake_case methods, SHOUTY_GLOBALS, etc).

I'm in favor of renaming. I like any_style because it's short and easy to spell, but #[deny(any_style)] doesn't make any sense to me. =)

Regarding whether this ought to have an RFC -- I could go either way; if we opt for no RFC, then we ought to at least do a "mini-FCP" here in the issue. TBH I'm not sure what team has ownership of lints though. =) I guess @rust-lang/lang?

[aturon]

I definitely don't feel this needs an RFC. I also wholeheartedly agree that we should change the name.

nonstandard_style or alternative_style seem good to me.

[whitequark]

alternative_style seem good to me

Do we really want the "alternative facts" connotation? I can already see someone writing that awful snark and the HN frontpage it'll hit and I'd really rather not have it.

[aturon]

@whitequark

Heh, I hadn't realized that the term "alternative" had gotten quite so poisoned! Anyway my preferences here aren't very strong.

[withoutboats]

I'm happy with any non-judgmental name, we can FCP the PR (I also don't care if we don't)

[whitequark]

FWIW I like the any_style suggestion as it makes no statement about the particular style in question. I am not worried at all about this change leading to more deviation from conventions because:

• humans are very good on exerting conformance pressure on their own, no need for the compiler assist;
• the fact that warnings are emitted by default already make anyone new to Rust stop and think;
• most Rust code is already uniform to a degree that I have not seen elsewhere, and there's no clear reason why that would suddenly change;
• rustfmt isn't going to be very configurable, further fossilizing the conventional style.

If something I'm worried there's too much friction for even minor deviations; I don't think I'll ever use rustfmt, for example.

[joshtriplett]

Given that this comes up often in code translators (such as corrode), and potentially in binding generators as well, then having a more neutral alias for this seems appropriate. I also don't think adding an alias needs an RFC.

I'm not going to add to the bikeshedding on the name itself. 🚳

[jseyfried]

any_style seems too broad -- it includes the standard style, so #![deny(any_style)] is weird.

I prefer nonstandard_style -- I think it's clearer than alternative_style since the latter could sound like we have an alternative in mind and isn't clear about to which it is alternative.

[est31]

As someone who has been annoyed by some C++ codebases that despite having official casing rules use different casing styles in parallel (including libraries using different casing styles), I am glad of those checks to be in the compiler and default on, because they create consistency. I believe this wish of consistency in this issue to be universal, so this isn't just a style issue where everyone can have its own, as your choice of casing gets forced upon the users of your library as well. I use tabs in my codebase and am writing let v :Type = try!(foo()) instead of let v: Type = foo()? so I'm not "mainstream" regarding style, but those choices don't escape my codebase so I'm comfortable doing them.

This check has many positive side effects. Like when reading code, you get accustomed to differentiate things inside lists of use clauses by their cases.

Looking at the issue from the other perspective, renaming the lint to nonstandard_style makes you feel intolerant when you type #![forbid(nonstandard_style)]. So one group gets always shamed.

Also, for beginners its important to see that the style they are doing is not fine, but rather something that is bad for the community of crates, especially their users, due to the inconsistency to the other crates on crates.io.

Overall though I don't feel very strongly about a rename, as long as the lint stays a warning by default.

[Manishearth]

renaming the lint to nonstandard_style makes you feel intolerant when you type #![forbid(nonstandard_style)]. So one group gets always shamed.

No more than #![forbid(bad_style)].

Beginners already see that the style is not great. This is just about making it possible to design your own beginner experience without feeling bad about it. This doesn't change the warning's existence, it just changes the name so that it isn't discouraging when disabled.

[est31]

One example for how the snake case style helps you to identify a bug: https://is.gd/XArdpj

You need to look twice to see that the last case in the match is creating a new variable instead of being an actual enum variant.

[skade]

@est31 I find this example rather contrived (it switches off multiple layers of safety and imports the matching shorthand).

Sure, "nonstandard_style" brings you half-way there, but the option is in the compiler and supported, this discussion is about an alias only.

[nikomatsakis]

@rfcbot fcp merge

I agree we don't need an RFC. I'm moving that we agree to change the name to nonstandard_style (and deprecate -- but naturally not remove! -- the old name bad_style).

[est31]

contrived

Its not a contrived example: I have encountered it in one of my programs. Luckily I had the bad_style lint turned on, so I didn't actually encounter the bug itself.

Sure, "nonstandard_style" brings you half-way there, but the option is in the compiler and supported, this discussion is about an alias only.

No, its about deprecation as well, and probably a Rust 2.0 or something will remove the name.

[Manishearth]

Most lints prevent bugs. That isn't an argument for giving it a name like that.

its about deprecation as well

deprecating the name, not the lint.

[Manishearth]

This was fixed in #48386

(looks like we forgot to unlock)

[carols10cents]

@Manishearth #48386 has a comment from you saying that it doesn't fix this issue completely, reopening because I don't see any other linked PRs

[Manishearth]

Oops, sorry!!

…

On Wed, Aug 29, 2018, 9:10 AM Carol (Nichols || Goulding) < ***@***.***> wrote: Reopened #41646 <#41646>. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#41646 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABivSK6jlQgnCk31NbUAIde7vYmvCI9Kks5uVrzWgaJpZM4NMg4Q> .

[mbrubeck]

Please direct comments about moderation to the moderators or to new forum threads.