Rust Rubric
This document lists conventions to follow when writing Rust in the Fuchsia Source Tree. These conventions are a combination of best practices, project preferences, and some choices made for the sake of consistency.
Guidelines
Naming
Casing conforms to Rust idioms
See C-CASE.
Ad-hoc conversions follow as_, to_, into_ conventions
See C-CONV.
Getter names follow Rust convention
With a few exceptions, the get_ prefix is not used for getters in Rust code.
See C-GETTER.
Methods on collections that produce iterators follow iter, iter_mut, into_iter
See C-ITER.
Iterator type names match the methods that produce them
See C-ITER-TY.
Names use a consistent word order
See C-WORD-ORDER.
Interoperability
Types eagerly implement common traits
Copy, Clone, Eq, PartialEq, Ord, PartialOrd, Hash, Debug, Display, Default should all be implemented when appropriate.
See C-COMMON-TRAITS.
Conversions use the standard traits From, AsRef, AsMut
See C-CONV-TRAITS.
Collections implement FromIterator and Extend
See C-COLLECT.
Data structures implement Serde's Serialize, Deserialize
See C-SERDE.
Types are Send and Sync where possible
See C-SEND-SYNC.
Error types are meaningful and well-behaved
See C-GOOD-ERR.
Binary number types provide Hex, Octal, Binary formatting
See C-NUM-FMT.
Generic reader/writer functions take R: Read and W: Write by value
See C-RW-VALUE.
Macros
Input syntax is evocative of the output
See C-EVOCATIVE.
Macros compose well with attributes
See C-MACRO-ATTR.
Item macros work anywhere that items are allowed
See C-ANYWHERE.
Item macros support visibility specifiers
See C-MACRO-VIS.
Type fragments are flexible
See C-MACRO-TY.
Documentation
Crate level docs are thorough and include examples
See C-CRATE-DOC.
All items have a rustdoc example
See C-EXAMPLE.
Note: this guideline is not reasonable to enforce for targets which build on Fuchsia until doctests are supported on Fuchsia targets. See #38215.
Examples use ?, not try!, not unwrap
See C-QUESTION-MARK.
Function docs include error, panic, and safety considerations
See C-FAILURE.
Prose contains hyperlinks to relevant things
See C-LINK.
Rustdoc does not show unhelpful implementation details
See C-HIDDEN.
Predictability
Smart pointers do not add inherent methods
See C-SMART-PTR.
Conversions live on the most specific type involved
See C-CONV-SPECIFIC
Functions with a clear receiver are methods
See C-METHOD.
Functions do not take out-parameters
See C-NO-OUT.
Operator overloads are unsurprising
See C-OVERLOAD.
Only smart pointers implement Deref and DerefMut
See C-DEREF.
Constructors are static, inherent methods
See C-CTOR.
Flexibility
Functions expose intermediate results to avoid duplicate work
See C-INTERMEDIATE.
Caller decides where to copy and place data
See C-CALLER-CONTROL.
Functions minimize assumptions about parameters by using generics
See C-GENERIC.
Traits are object-safe if they may be useful as a trait object
See C-OBJECT.
Type safety
Newtypes provide static distinctions
See C-NEWTYPE.
Arguments convey meaning through types, not bool or Option
See C-CUSTOM-TYPE.
Types for a set of flags are bitflags, not enums
See C-BITFLAG.
Builders enable construction of complex values
See C-BUILDER.
Dependability
Functions validate their arguments
See C-VALIDATE.
Destructors never fail
See C-DTOR-FAIL.
Destructors that may block have alternatives
See C-DTOR-BLOCK.
Debuggability
All public types implement Debug
See C-DEBUG.
Debug representation is never empty
See C-DEBUG-NONEMPTY.
Future Proofing
Sealed traits protect against downstream implementations
See C-SEALED.
Structs have private fields
See C-STRUCT-PRIVATE.
Newtypes encapsulate implementation details
See C-NEWTYPE-HIDE.
Data structures do not duplicate derived trait bounds
See C-STRUCT-BOUNDS.
Updating the guidelines
This rubric is currently maintained by the Rust on Fuchsia Working Group. To propose additions or modifications, open a CL and cc fuchsia-rust-api-rubric@google.com to ensure it is reviewed.
Relationship with upstream Rust API guidelines
This rubric contains most of the Rust API Guidelines, however the following official guidelines are omitted:
- C-FEATURE as Fuchsia does not currently support features for crates.
- C-METADATA as Fuchsia does not maintain internal
Cargo.toml files. - C-HTML-ROOT as Fuchsia does not currently publish most Rust code to
crates.io. - C-RELNOTES as most Rust code in Fuchsia “lives at HEAD”.
- C-STABLE as Fuchsia does not currently publish most Rust code to
crates.io. - C-PERMISSIVE as all of Fuchsia's Rust code is under the Fuchsia license.