code-quality

コード品質ガイド

中核となる原則

本番データベースです。正しさが最優先です。クラッシュするほうが、データを破損させるよりもましです。

正しさに関するルール

1. 回避策やその場しのぎのハックは使わないでください。 すべてのエラーに対処し、不変条件を確認してください
2. 頻繁にアサートしてください。 失敗を黙って無視したり、エッジケースを握りつぶしたりしないでください
3. データの整合性が損なわれるおそれがある場合は、無効な状態でクラッシュさせてください。未定義の状態で処理を続けないでください
4. エッジケースを考慮してください。 十分に長い時間が経てば、あらゆるバグが起こり得ます

Rust のパターン

• 不正な状態を表現できないようにする
• 網羅的なパターンマッチングを使う
• 文字列やセンチネル値よりも enum を優先する
• ヒープ割り当てを最小限にする
• CPU に優しいコードを書く（マイクロ秒でも長い時間です）

if 文

誤り：

if condition {
    // happy path
} else {
    // "shouldn't happen" - silently ignored
}

正しい例：

// If only one branch should ever be hit:
assert!(condition, "invariant violated: ...");
// OR
return Err(LimboError::InternalError("unexpected state".into()));
// OR
unreachable!("impossible state: ...");

if 文は、両方の分岐が想定される場合にのみ使用してください。

コメント

• Rust の SAFETY コメントを除き、コードコメントを追加しないでください。

過剰な設計を避ける

• 直接依頼された変更、または明らかに必要な変更だけを行う
• 依頼された範囲を超える機能を追加しない
• 変更していないコードに docstring やコメントを追加しない
• 起こり得ない状況に対するエラー処理を追加しない
• 一度しか使わない処理のために抽象化を作らない
• 早まった抽象化をするより、似た行を3行書くほうがよい

インデックスの変更

コードでインデックスの挿入、削除、競合解決を行う場合は、SQLite に対する順序を再確認してください。順序を誤るとインデックスの不整合が発生し、見落としやすいためです。

IO モデルを理解する

• 非同期 IO モデル

クリーンアップ

• 使われていないコードは完全に削除する
• 後方互換性のためのハック（名前を変更した _vars、再エクスポート、// removed コメント）を行わない

1回のみ使用するヘルパー

ヘルパー関数が単一のユースケース以外では意味を持たない場合は、その関数を使用する関数の中に移動してください：

fn do_something() {
    
    something_specific();

    fn something_specific() {
    }
}