Rust Style Guide

TL;DR

Buying for a business?Offer from Amazon

Get business pricing on monitors, keyboards and dev gear

• Business-only prices and quantity discounts
• Tax-exempt purchasing
• Multiple users, one account, clear invoices

Create a free Business account →Free to register

As an affiliate, we earn on qualifying purchases.Hide

Google’s Rust Style Guide sets out recommendations for formatting, API design, code organization and implementation across its Rust codebases. Google says the guidance aims to support readable, maintainable code and large-scale changes, while Android, Chromium and other projects may apply it under their own rules.

Google has published a Rust Style Guide that covers far more than formatting, setting out recommendations for API design, ownership, code organization, concurrency and implementation. The document is intended to make Rust code more consistent across Google projects, though the company says adoption in Android, Chromium and other codebases may follow those projects’ own rules.

The guide says its scope is Rust usage at Google, including code in google3, Android, ChromeOS, Fuchsia and Chrome. Its recommendations range from familiar conventions, such as using rustfmt for automatic formatting, to design choices about function inputs and outputs, error reporting, traits and public APIs. The document also tells developers to follow public Rust style rules where they do not conflict with Google’s guidance.

Several recommendations address ownership and API design. The guide advises developers to prefer borrows over deep copies, accept flexible references for immutable data, and consider iterators or slices instead of returning or accepting owned collections where appropriate. For APIs, it favors enums over booleans, named fields over tuples in many cases, and explicit constructors alongside important From implementations.

Implementation advice includes preferring pattern matching to checking and then unwrapping, using expect rather than unwrap when a failure needs explanation, and avoiding iterator chains when a direct loop is clearer. The source also includes codebase-specific rules marked for Chrome or Fuchsia, such as guidance on library layout and mutex use; these labels indicate that not every recommendation applies uniformly to every project.

One Guide, Different Codebases

The document matters because it treats style as a tool for maintainability and API quality, not just a way to make files look alike. Shared conventions can reduce repeated debates in code review and make large changes across many files easier to carry out. Google specifically cites large-scale changes, or LSCs, as a reason consistency is useful.

Its reach is not automatic or identical across all projects. Google says the guide was developed in consultation with other codebases and that Android, Chromium and others intend to start applying it, but that each may have its own expectations about how strictly the rules are enforced. For developers working across those projects, the guide offers a shared reference; the practical effect will depend on local adoption.

Guidance Beyond Formatting

Google frames the guide around goals that include readability, maintainability and automation. It says rules should generally align with the wider Rust ecosystem to reduce surprises, while also serving Google’s needs for large-scale code changes. The guide acknowledges that some rules settle disagreements where multiple stylistic choices are reasonable, but says such rules should be limited when they offer no other benefit.

Formatting is only one part of that approach: the source says most formatting conventions are enforced automatically by rustfmt. Other sections address documentation, naming, macros, unsafe code, testing and public type design, including when to use #[non_exhaustive] and #[must_use]. Some guidance is explicitly scoped to particular projects, and the document points developers to public Rust style rules and API guidelines where Google has not set a conflicting rule.

“Style rules should prioritize readability and maintainability over writeability.”

— Google Style Guides

Adoption Rules Remain Local

The source does not specify a single enforcement date or a uniform compliance process for all Google projects. It says Android, Chromium and other codebases intend to begin applying the guide, while leaving room for local differences in how strictly they do so. It also does not provide a project-by-project schedule or describe how developers should resolve conflicts between this guide and local rules.

The supplied material does not state how the guide will be updated, who will oversee adoption, or whether compliance will be checked automatically beyond formatting handled by rustfmt. Its project-specific labels make clear that some recommendations have narrower scope, but the excerpt does not establish the current status of each codebase’s implementation.

Project Teams Set Application

The next step described in the guide is for Android, Chromium and other codebases to begin applying the recommendations under their own rules. Google says further information is expected as those projects adopt the guide, but the source gives no firm dates or milestones. Developers will need to consult their local project guidance to determine which recommendations apply and how they are enforced.

Key Questions

What is Google’s Rust Style Guide?

It is Google’s guidance for writing and organizing Rust code, covering formatting as well as API design, ownership, concurrency, documentation and implementation practices.

Does the guide apply to every Google project in the same way?

No. Google says Android, Chromium and other codebases may set their own expectations for how strictly the guide is applied. Some individual rules are also marked for specific projects.

Does the guide replace the public Rust style rules?

The document says developers should follow public Rust style rules where they do not conflict with Google’s guide. Google presents its recommendations as an additional, company-specific layer.

What does the guide recommend about ownership?

Among other points, it advises developers to prefer borrows over deep copies and to use flexible references for immutable data when suitable. The guide also discusses when to use iterators, slices and owned collections.

When will the guidance be enforced?

The supplied source gives no universal enforcement date. It says adoption details will vary by codebase and that more information is expected as projects begin applying the rules.

Source: hn