Naming conventions

General conventions [RFC #430]

The guidelines below were approved by RFC #430.

In general, Rust tends to use CamelCase`CamelCasefor "type-level" constructs (types and traits) and` for "type-level" constructs (types and traits) and snake_case`snake_case` for "value-level" constructs. More precisely:

Item Convention
Crates snake_case`snake_case` (but prefer single word)
Modules snake_case`snake_case`
Types CamelCase`CamelCase`
Traits CamelCase`CamelCase`
Enum variants CamelCase`CamelCase`
Functions snake_case`snake_case`
Methods snake_case`snake_case`
General constructors new`newor` or with_more_details`with_more_details`
Conversion constructors from_some_other_type`from_some_other_type`
Local variables snake_case`snake_case`
Static variables SCREAMING_SNAKE_CASE`SCREAMING_SNAKE_CASE`
Constant variables SCREAMING_SNAKE_CASE`SCREAMING_SNAKE_CASE`
Type parameters concise CamelCase`CamelCase, usually single uppercase letter:`, usually single uppercase letter: T`T`
Lifetimes short, lowercase: 'a`'a`

In CamelCase`CamelCase, acronyms count as one word: use`, acronyms count as one word: use Uuid`Uuidrather than` rather than UUID`UUID. In`. In snake_case`snake_case, acronyms are lower-cased:`, acronyms are lower-cased: is_xid_start`is_xid_start`.

In snake_case`snake_caseor` or SCREAMING_SNAKE_CASE`SCREAMING_SNAKE_CASE, a "word" should never consist of a single letter unless it is the last "word". So, we have`, a "word" should never consist of a single letter unless it is the last "word". So, we have btree_map`btree_maprather than` rather than b_tree_map`b_tree_map, but`, but PI_2`PI_2rather than` rather than PI2`PI2`.

Referring to types in function/method names [RFC 344]

The guidelines below were approved by RFC #344.

Function names often involve type names, the most common example being conversions like as_slice`as_slice`. If the type has a purely textual name (ignoring parameters), it is straightforward to convert between type conventions and function conventions:

Type name Text in methods
String`String` string`string`
Vec<T>`Vec` vec`vec`
YourType`YourType` your_type`your_type`

Types that involve notation follow the convention below. There is some overlap on these rules; apply the most specific applicable rule:

Type name Text in methods
&str`&str` str`str`
&[T]`&[T]` slice`slice`
&mut [T]`&mut [T]` mut_slice`mut_slice`
&[u8]`&[u8]` bytes`bytes`
&T`&T` ref`ref`
&mut T`&mut T` mut`mut`
*const T`*const T` ptr`ptr`
*mut T`*mut T` mut_ptr`mut_ptr`

Avoid redundant prefixes [RFC 356]

The guidelines below were approved by RFC #356.

Names of items within a module should not be prefixed with that module's name:

Prefer

fn main() { mod foo { pub struct Error { ... } } }
mod foo {
    pub struct Error { ... }
}

over

fn main() { mod foo { pub struct FooError { ... } } }
mod foo {
    pub struct FooError { ... }
}

This convention avoids stuttering (like io::IoError`io::IoError`). Library clients can rename on import to avoid clashes.

Getter/setter methods [RFC 344]

The guidelines below were approved by RFC #344.

Some data structures do not wish to provide direct access to their fields, but instead offer "getter" and "setter" methods for manipulating the field state (often providing checking or other functionality).

The convention for a field foo: T`foo: T` is:

Note that this convention is about getters/setters on ordinary data types, not on builder objects.

Escape hatches [FIXME]

[FIXME] Should we standardize a convention for functions that may break API guarantees? e.g. ToCStr::to_c_str_unchecked`ToCStr::to_c_str_unchecked`

Predicates