RFC: Finalizing more naming conventions

[aturon]

This conventions RFC tweaks and finalizes a few long-running de facto
conventions, including capitalization/underscores, and the role of the unwrap method.

See this RFC for a competing proposal for unwrap.

Rendered

Note: Though marked as closed, this RFC was in fact accepted.

[alexcrichton]

Constants as well, right?

[reem]

I think we should consider CamelCase for constants, since SCREAMING_SNAKE_CASE is extremely abrasive to look at and it more clearly demonstrates the difference.

[alexcrichton]

Note that there are precedents in both directions here, and I'm not sure it's clear that we should draw a distinction between these two kinds of variables.

Looking around, we've got:

• All caps: Python, Ruby, Java, Javascript
• Camel case: C++ (kinda), Go (I think),

I'll also point out that "SCREAMING_SNAKE_CASE" is abrasive probably because it has the word "screaming" in all caps. Something like MAX_WIDTH vs MaxWidth seems less abrasive to me

[utkarshkukreti]

I was going to use enums to represent keys in a termbox-like console input library, but it turns out that Ctrl-I and Tab keys map to the same escape sequence so I'll have to use CTRL_I and TAB instead of CtrlI and Tab now if I want to use it in a match :(

[glaebhoerl]

I think consts (as opposed to statics) should be CamelCase. Two reasons: lines up with enum variants, which they are semantically most similar to, and we can say that CamelCase is for "compile-time (known) things" (which types and constants both fall under).

[brendanzab]

Yup. I agree with @glaebhoerl on this. Either that or make variants screaming, but I don't think anyone wants that!

[arcto]

I agree with @glaebhoerl in that constants and enum variants should share the same CamelCase. After all, enum variants are a kind of constant.

I think it's fair though that static variables stand out (using SCREAMING_SNAKE_CASE). They are a different beast -- especially mutable ones.

[glaebhoerl]

That's the other idea I was going to float... perhaps it might make sense to distinguish mutable statics from immutable ones. Meaning that: we use normal snake_case for statically allocated immutable data (which is totally harmless), just like lets, and SCREAMING_SNAKE_CASE for both static muts and plain statics with any kind of interior mutability ("global mutable state, oh my!").

[brson]

This discusses acronyms in camel case but not snake case: e.g. is_XID_Start should probably be is_xid_start.

[netvl]

Especially big +1 for unwrap()/into_inner() convention. I think it is much better than renaming unwrap() on Option/Result.

[thepowersgang]

Just to leave my two cents on the topic of statics. I'm all for "screaming case" (Caps) for constants, but for interior mutable data (StaticMutex) using snake case would be preferable. [Similar to @glaebhoerl's comment]

[glaebhoerl]

(That's actually the reverse of my comment.)

[nikomatsakis]

Isn't the convention not new_with_more_details but rather with_more_details?

[aturon]

@nikomatsakis

Isn't the convention not new_with_more_details but rather with_more_details?

Good catch! This was leftover from the original wiki that I started with. I will update.

[brson]

Accepted. Discussion. Tracking.

[brson]

Accidentally rebased this instead of merged.

[chpiatt]

Just came here to point out that ThisNamingConvention is more accurately referred to as Pascal Case. In the documentation you refer to it as Camel Case, which more commonly follows thisPattern.

[gomesalexandre]

Hey, just came here to state the same thing as @Pyython. You refer to PascalCase as CamelCase, while camel casing has the first letter not capitalized(camelCase).
Any chance of modifying it in the docs? 🙏

[nikomatsakis]

By docs, do you mean the RFC? Ideally, we'd have these docs living somewhere else and update there, but I'm not sure if they do. We don't generally modify the text of RFCs heavily after they're landed, prefering to keep more stable docs up to date.

[shepmaster]

This has already been addressed by #2389 and your duplicate issue #2849.