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`.
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` |
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.
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:
foo(&self) -> &T
`foo(&self) -> &T` for getting the current value of the field.set_foo(&self, val: T)
`set_foo(&self, val: T)for setting the field. (The
` for setting the field. (The val
`valargument here may take
` argument
here may take &T
`&T` or some other type, depending on the context.)Note that this convention is about getters/setters on ordinary data types, not on builder objects.
[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`
is_
`is_or another short question word, e.g.,
` or another
short question word, e.g., is_empty
`is_empty`.lt
`lt,
`, gt
`gt`, and other established predicate names.