🦀 Google Rust スタイルガイド: 重要なポイント

Tip: TL;DR: 可読性 > 書きやすさ。rustfmt + パブリック Rust 規約に従う。魔法（マクロ、グロブ、Rc、unsafe、unwrap）を避ける。所有権、エラー、型について明示的に。

🧭 Step 0: 基本ルールを理解する

すべてのルールの背景にある目標

目標	意味
📖 可読性を優先	コードは長く存在する。書く際にもう少し努力をかける
🤖 自動化に対応	一貫したコードは大規模リファクタリング（LSCs）を容易にする
🌍 エコシステムに合わせる	公式 Rust スタイルガイド + Rust API ガイドラインに従う（このガイドと矛盾しない限り）
⚖️ ルールは重みを持つ必要がある	実際の効果があるルールのみ
🛑 自転車置き場問題を終わらせる	よくある意見の相違を一度解決する

ライブラリコード vs アプリケーションコード

	ライブラリコード	アプリケーションコード
使用者	他のプロジェクト	1つのアプリ
API 設計ルール	拘束力がある	強い推奨
考え方	柔軟、汎用、再利用可能	シンプル、直接的、過度な抽象化なし

📁 Step 1: コードを整理する

小さなクレートを優先（Chromium）: 理想的には 1 つのファイル、1 つの抽象。サブモジュールを追加する前に分割する。
フラットなファイルレイアウト（Chromium）: 1 つのクレートの .rs ファイルは 1 つのディレクトリに存在する。サブディレクトリが必要 = クレートが大きすぎる。
ファイル名を主要項目の後に付ける: struct Foo → foo.rs / mod foo。
リーフでないモジュールは mod 宣言と再エクスポートのみを保持し、実装は含まない（少しのグルーコードは OK）。リーフモジュールは mod test とバインディングモジュール（例: #[cxx::bridge]）を含むことができる。
ルートモジュールはリーフサブモジュールからパブリック API を再エクスポートできるため、サブモジュールは実装詳細のままになる。
API が同じクレートに属するかどうかを最初に決定し、その後でサブモジュールを検討する。
トレイト実装の一貫性ルールが型とトレイトを一緒に強制する場合、または大規模な基礎ライブラリの場合、大きなクレートは問題ない。
例外: Cargo でも構築される //third_party コードは通常の Cargo ディレクトリレイアウトを保つ。

📦 Step 2: インポートを正しく書く

❌ グロブインポートなし

許可される例外のみ:

use super::* インラインモジュール内（例: mod test）
use MyEnum::* そのエナムを主に扱う関数内
pub use submodule::* リーフでないモジュール内
C++ 名前空間を 1 つのモジュールにマージ（マージされたモジュールは公開されていない必要がある）
サードパーティプリルード（レビュアーの判断）。独自のプリルードを定義しないでください。

✅ `use` ステートメントごとに 1 つのモジュール

rustfmt 設定 imports_granularity = Module に合致（{} 内に ::なし）:

// ✅ Good
use foo::Foo;
use foo::bar::{Bar, Baz};

// ❌ Bad
use foo::{Foo, bar::Bar};

✅ トレイトをローカルでインポート

トレイトのメソッドがファイル全体で広く使用されている場合を除く。

fn foo(s: &str) -> Result<u8, std::num::ParseIntError> {
    use std::str::FromStr; // 使用されている場所にスコープされている
    u8::from_str(s)
}

✅ 関数: モジュール名で修飾

// ✅ Good
use std::mem;
let x = mem::transmute(y);

// ❌ Bad
use std::mem::transmute;
let x = transmute(y);

例外: 明確に区別される名前（例: C++ フリー関数）、小さな単一目的のファーストパーティクレート（Chromium）、衝突しやすいモジュール名（例: C++ 名前空間名）。

✅ 型: インポートして非修飾で使用

regex::Regex ではなく Regex と書く。例外: あいまいな名前（io::Error または use std::io::Error as IoError）、大規模な型グループ（例: rustc の hir）、マクロ/生成コード、多くの依存関係があるため import ブロックが巨大になるコード。

Chromium のみ

chromium::import!() をインポート機構として使用してください。

🎨 Step 3: フォーマット

フォーマッターを実行（rustfmt / git cl format）。フォーマットについて手動で議論しないでください。
推奨される rustfmt オプション（コードベースは安定版 Rust で利用できないものをスキップできます）:

max_width = 100
hex_literal_case = "Lower"   # 0xab12, not 0xAB12
format_macro_matchers = true
imports_granularity = "Module"

リテラル内の目に見えない文字をエスケープ: \u{200D}。
#[rustfmt::skip] のみ意図的な手動配置（例: 行列）または生成されたコード用。個人的な好みには決して使わないでください。

🔐 Step 4: 所有権と借用

ルール	詳細
`Rc` / `Arc` を避ける	単一所有権 + 借用を優先。代替案が非常に複雑な場合のみ使用。
`.clone()` より借用を優先	深いコピーが本当に必要な場合のみクローンする。`Rc`/`Arc` のクローンは問題ない（安価なポインタコピー）。

🔌 Step 5: 関数入力と出力

最も柔軟な参照を受け入れる

✅ 使用	❌ 代わりに
`&T`	`&Box<T>`
`&[T]`	`&Vec<T>`
`&str`	`&String`
`Option<&T>`	`&Option<T>`

例外: Rope/Cord のような非線形文字データ。関連する Clippy リント: borrowed_box、ptr_arg。

イテレータ vs コレクション

状況	ライブラリ	アプリケーション
戻り値	`impl Iterator` を優先	より単純な場合は `Vec<T>` で問題ない
パラメータ	`impl IntoIterator` を受け入れる	より単純な場合は `&[T]` で問題ない

次の場合は Vec を返す: ほとんどの呼び出し元が Vec を必要とする、実装が自然に 1 つを構築する、結果がランダムアクセスを必要とする、for ループがより適切で割り当てが問題でない、関数の目的がコレクションを作成することである、または既存のベクトルを返す。

その他の入力ルール

impl Into<T> パラメータ: ライブラリのみ、呼び出しサイトの使いやすさが本当に重要な場合。コードブロート、複雑な署名、推論の問題に対してバランスを取る。アプリケーションコード: ほぼ決してない。
意味が明確でない場合、bool より enum を優先する。bool を保持する場合、呼び出しサイトでコメント:

connect(addr, /* retry= */ true);

🚨 Step 6: エラーを正しく報告する

メカニズム	時期	例
`Option`	明白で予期される失敗。詳細は不要	`checked_add() -> Option<u32>`
`Result`	回復可能な外部エラー。呼び出し元は理由を知る必要がある	`open_file() -> Result<File, io::Error>`
`panic!`	バグ / 違反した不変条件: コードを修正し、実行時に処理しない	インデックス範囲外

パニックからの粗粒度の回復は catch_unwind で可能（Step 14 の制限を参照）。例外: 開発用バイナリとテストはパニックできる。一部のコードベースはパニックを完全に禁止し、破損した不変条件でも Result を使用。

🧱 Step 7: 型

Newtype vs 型エイリアス。 次の場合に newtype を使用:

セマンティクスが基礎となる型と異なる
型が独自の API を必要とする
後で基礎となる型を変更する可能性がある
型が混同しやすい（例: Day、Month、Year）

タプルより名前付きフィールド:

// ✅ Good
struct Point { x: f64, y: f64 }

// ❌ Avoid (except one-field newtypes or very local use)
let p = (1.0, 2.0); p.0; p.1;

🧩 Step 8: トレイト

トレイトを定義する時期

のみ:

ジェネリック境界（T: Trait）
impl Trait / dyn Trait
拡張トレイトそれ以外 → 固有の impl。コードの整理にトレイトを使用しないでください。

一般的なトレイトルール

ライブラリコード: impl をプロアクティブに追加。アプリケーションコード: 必要な場合に追加。
カスタムメソッドの代わりに std トレイトを実装（fn from_str ではなく impl FromStr）。メソッドとトレイト impl の両方を保持することは見つけやすさのため問題ない（Clippy: should_implement_trait）。
可能な限り #[derive(...)] を使用。
ライブラリ: dyn Trait よりジェネリクスを優先（ファットポインタやvtable検索なし、インライン可能）。コードサイズが問題でない限り。注意: 一部のトレイトは dyn 互換ではない（ジェネリックメソッド、self のない関連関数、Self を返すメソッド）。

拡張トレイト

サフィックス Ext → ForeignTypeExt
型を所有するチームが拡張を所有する（メソッド名の衝突を回避）。
例外: 基礎ライブラリ/フレームワークで広く有用な拡張。
入力トレイト（例: 多くの外部型で実装される DateLike）と混同されないこと。入力トレイトは問題ない。
ブランケット実装も可能: impl<T: ForeignTrait> ForeignTraitExt for T。

トレイトチートシート

トレイト	ガイダンス
`Copy`	`Copy` のままであることが明確な場合に実装。エラー型: 可能な限り `Copy`。
`Clone`	ほとんどの型（外部リソースを表す型は除く）
`Default`	`new()` がある、またはデフォルト状態がある場合
`PartialEq` / `PartialOrd`	`==` / `<` にはこれらを優先。`Eq` / `Ord` は反射性/全順序を保証する場合のみ追加。
`Hash` + `Eq`	マップキーやキャッシュキーとして使用される可能性がある場合。明確な全順序がある場合は `Ord` も追加。
パブリックフィールドのある型	すべてのサブフィールドが実装するトレイトの実装を検討
`From`	主なコンストラクタの場合、`new()` / `from_foo()` も追加
オプション構造体	`Default` を実装 → `..Default::default()` を有効にする

🧵 Step 9: 並行性

決してポイズンされたミューテックスに手を出さない。
Chromium: async/.await なし、std::thread なし（シーケンスを使用）。
Fuchsia: fuchsia_sync::Mutex を使用。

🪄 Step 10: マクロ（最後の手段）

優先順位:

プレーン関数、型、トレイト、モジュール ✅
macro_rules!
その他のコード生成（例: genrule）
proc_macro ⚠️ 理由: マクロは IDE サポートを損なわせ、ミニ言語を作成し、LSCs を難しくする。コード生成が必要な場合、macro_rules! は AST で動作するため、テキスト生成より脆弱性が低い。

🏷️ Step 11: 命名

項目	規約
変換	`as_..()` （安価な借用）、`to_..()` （高価）、`into_..()` （self を消費）
コンストラクタ	`new()`、`new_with_foo()`、`Result` を返す場合は `try_new()`
値の変換	`from_foo()` + マッチング `From` impl
拡張トレイト	`FooExt`
ライフタイム	説明的な名前。`'a` は単純な入力→出力リンクまたはローカル `for<'a>` 境界で OK（最大 2）。`'_` は問題ない。`Cow` のようなジェネリック抽象化は免除。
ジェネリクス	短く、意味のある（主なトレイト境界から）。`T`/`U` は非境界ジェネリクス用。
省略形	一般的な場合（Wikipedia 上）またはプロジェクト外で明確な場合を除く避ける（例: `IpAddr`）。単語内の文字を削除しない。

ゲッター & セッター

メソッド	目的
`foo()`	`&T` を返す（または `Copy` の場合は `T`）。`get_` プレフィックスなし。
`foo_mut()`	`&mut T` を返す
`set_foo(v)`	値を設定
`take_foo()`	デフォルト/`None` をクリア、古い値を返す
`replace_foo(v)`	値を設定、古い値を返す
`with_foo(\|f\| ..)` / `with_mut_foo(\|f\| ..)`	クロージャアクセス。`Mutex`/`RefCell`（ガードをリークさせない）やガードが変更後の検証を必要とする場合に最適。クロージャの戻り値は返される。アクセサが 1 つだけの場合、`with_foo` も変更できる。

📝 Step 12: ドキュメント

すべてのパブリック API をドキュメント化（missing_docs リントを使用）。
/// は項目、//! はモジュール/クレート（ファイルの先頭）、// は実装ノートと TODO。混ぜることが推奨。
Markdown、大文字化、句読点を使用。
常にパニックケースをドキュメント化する及び unsafe 不変条件。
どこかのクレートに例を含める（すべての関数に必要なわけではない）。
言語の基本を説明しない（例: テスト用モック実装に関する「トレイトのモック実装」）。
自明なエナム変種のドキュメントは省略可能。
マクロから生成されるのではなく、/// / //! で直接ドキュメント化。
明白なことを言い直さない:

// ❌ 無意味（省略して lint を許可する方が良い）
/// 要素を削除します。
pub fn remove_element() -> Element {}

// ✅ 有用: パブリック doc + プライベートノート
/// 与えられた `name` を持つ最初の `FooItem` を見つけるか、存在しない場合は `None`。
// TODO: crbug.com/12345 - `name` は String ではなく &str にすべき。
pub fn get_named(items: &[FooItem], name: String) -> Option<&FooItem> { .. }

⚙️ Step 13: その他の言語機能

トピック	ルール
`unsafe`	安全な代替案がない場合のみ。安全な抽象に分離し、`// SAFETY:` コメントを追加し、正当化する（パフォーマンスの場合はベンチマークで）。
不安定な機能	使用しないこと。例外: Android 組み込みニーズ（レビュー済み）、Chrome 承認リスト、Fuchsia の独自ガイダンス
`len()`	`is_empty()` も実装
`#[doc(hidden)]`	所有していない場合はプライベートとして扱う
`const fn`	`const` のままにされる場合のみ（削除すれば破壊的変更）
オペレータオーバーロード	実際の数学/論理的意味がある場合のみ。構文シュガーではない。
パブリックエナム（他のチームが使用）	`#[non_exhaustive]` セットが固定（例: `Color`、二状態エナム）またはLSC による破壊修正をコミット。稀に使用されるエナムはスキップ可能。
パブリック構造体（pub フィールド付き）	`#[non_exhaustive]` フィールドが変更されない、LSC 修正をコミット、または `..Default::default()` が必要な場合を除く
`#[must_use]`	純粋関数（例: `HashMap::get`）、重要な情報を返す関数、エラー / 遅延型。戻り型が既に `#[must_use]`（例: `Result`）の場合は不要。
`main()` 前のコード	決してない（例: `ctor` クレート）

🛠️ Step 14: 実装習慣

推論が隠すところに明示的な型を追加

特に .into() の後、.parse() と複雑なイテレータチェーン。ターボフィッシュより変数の注釈を優先:

let port: u16 = s.parse()?;

コンパイラがターボフィッシュを強制する場合、_ マーカーは問題ない: collect::<Vec<_>>()。

チェック→アンラップの代わりにパターンマッチ

// ✅ Good
if let Some(value) = option {
    use_value(value);
}

// ❌ Bad
if option.is_some() {
    use_value(option.unwrap());
}

`unwrap` より `expect`

不変条件がなぜ成立するかドキュメント: .expect("config loaded at startup")。

`#[non_exhaustive]` エナムのマッチング

既知の変種を明示的に列挙し、その後 _:

match shape {
    Shape::Circle => println!("circle"),
    Shape::Square => println!("square"),
    Shape::Triangle | _ => {}
}

// ✅ 1 つの変種のみ気にする → if let
if let Shape::Circle = shape { println!("circle"); }

// ❌ 変種を _ の後ろに隠す
match shape {
    Shape::Circle => println!("circle"),
    _ => {}
}

例外: 一部の変種のみ気にし、if let より match がより読みやすい場合は問題ない。

アサーションにコンテキストを与える

// ✅ なぜかを説明
assert!(values.is_sorted(), "`values` は PriorityQueue から来ているため、ソート済みであるべき");
assert!(refund > 0, "払い戻しは正数である必要があり、{refund:?} を得た");
assert!(self.stream.is_some(), "クエリを実行する前に connect() を呼び出す");

// ❌ 条件を繰り返すだけ
assert!(values.is_sorted(), "values は常にソート済みであるべき");

イテレータチェーン vs `for` ループ

✅ 短く、ロジック重視の組み合わせ: values.iter().any(|&v| v > threshold)
❌ 条件や外部変更を伴う長いチェーン → for ループを使用
❌ for ヘッダー内のチェーン → 最初に名前付き変数に割り当てる
❌ for_each → 通常は for ループの方が読みやすい

let urgent_bugs = bug_descriptions
    .iter()
    .filter_map(|d| parse_bug_description(d).ok())
    .filter(|bug| bug.priority <= Priority::P1);

for bug in urgent_bugs {
    assign_bug(bug);
}

その他の習慣

panic::catch_unwind なし。防守的な深さとしてのみ許可され、コードは何にも依存しない、かつコードが panic=unwind で実行される場所でのみ（Chrome、Android、Fuchsia は panic=abort を使用）。
文字列: a + b + c の代わりに format!("{a}{b}{c}") （割り当てが少ない）または str::replace テンプレート。独自のテンプレート構文を発明しないこと。
テスト: コードベースのフレームワークを使用（Chrome: rust_gtest_interop、Fuchsia: #[fuchsia::test]）。

🦀 Google Rust スタイルガイド: 重要なポイント

🧭 Step 0: 基本ルールを理解する

📁 Step 1: コードを整理する

📦 Step 2: インポートを正しく書く

❌ グロブインポートなし

✅ `use` ステートメントごとに 1 つのモジュール

✅ トレイトをローカルでインポート

✅ 関数: モジュール名で修飾

✅ 型: インポートして非修飾で使用

Chromium のみ

🎨 Step 3: フォーマット

🔐 Step 4: 所有権と借用

🔌 Step 5: 関数入力と出力

最も柔軟な参照を受け入れる

イテレータ vs コレクション

その他の入力ルール

🚨 Step 6: エラーを正しく報告する

🧱 Step 7: 型

🧩 Step 8: トレイト

トレイトを定義する時期

一般的なトレイトルール

拡張トレイト

トレイトチートシート

🧵 Step 9: 並行性

🪄 Step 10: マクロ（最後の手段）

🏷️ Step 11: 命名

ゲッター & セッター

📝 Step 12: ドキュメント

⚙️ Step 13: その他の言語機能

🛠️ Step 14: 実装習慣

推論が隠すところに明示的な型を追加

チェック→アンラップの代わりにパターンマッチ

`unwrap` より `expect`

`#[non_exhaustive]` エナムのマッチング

アサーションにコンテキストを与える

イテレータチェーン vs `for` ループ

その他の習慣

✅ クイックレビューチェックリスト

Related Articles

🧭 Step 0: 基本ルールを理解する​

📁 Step 1: コードを整理する​

📦 Step 2: インポートを正しく書く​

❌ グロブインポートなし​

✅ use ステートメントごとに 1 つのモジュール​

✅ トレイトをローカルでインポート​

✅ 関数: モジュール名で修飾​

✅ 型: インポートして非修飾で使用​

Chromium のみ​

🎨 Step 3: フォーマット​

🔐 Step 4: 所有権と借用​

🔌 Step 5: 関数入力と出力​

最も柔軟な参照を受け入れる​

イテレータ vs コレクション​

その他の入力ルール​

🚨 Step 6: エラーを正しく報告する​

🧱 Step 7: 型​

🧩 Step 8: トレイト​

トレイトを定義する時期​

一般的なトレイトルール​

拡張トレイト​

トレイトチートシート​

🧵 Step 9: 並行性​

🪄 Step 10: マクロ（最後の手段）​

🏷️ Step 11: 命名​

ゲッター & セッター​

📝 Step 12: ドキュメント​

⚙️ Step 13: その他の言語機能​

🛠️ Step 14: 実装習慣​

推論が隠すところに明示的な型を追加​

チェック→アンラップの代わりにパターンマッチ​

unwrap より expect​

#[non_exhaustive] エナムのマッチング​

アサーションにコンテキストを与える​

イテレータチェーン vs for ループ​

その他の習慣​

✅ クイックレビューチェックリスト​

Related Articles

🧭 Step 0: 基本ルールを理解する

📁 Step 1: コードを整理する

📦 Step 2: インポートを正しく書く

❌ グロブインポートなし

✅ `use` ステートメントごとに 1 つのモジュール

✅ トレイトをローカルでインポート

✅ 関数: モジュール名で修飾

✅ 型: インポートして非修飾で使用

Chromium のみ

🎨 Step 3: フォーマット

🔐 Step 4: 所有権と借用

🔌 Step 5: 関数入力と出力

最も柔軟な参照を受け入れる

イテレータ vs コレクション

その他の入力ルール

🚨 Step 6: エラーを正しく報告する

🧱 Step 7: 型

🧩 Step 8: トレイト

トレイトを定義する時期

一般的なトレイトルール

拡張トレイト

トレイトチートシート

🧵 Step 9: 並行性

🪄 Step 10: マクロ（最後の手段）

🏷️ Step 11: 命名

ゲッター & セッター

📝 Step 12: ドキュメント

⚙️ Step 13: その他の言語機能

🛠️ Step 14: 実装習慣

推論が隠すところに明示的な型を追加

チェック→アンラップの代わりにパターンマッチ

`unwrap` より `expect`

`#[non_exhaustive]` エナムのマッチング

アサーションにコンテキストを与える

イテレータチェーン vs `for` ループ

その他の習慣

✅ クイックレビューチェックリスト