この記事のポイント

• 戻り値nullable設計のレビュー観点を体系整理
• nullable採用根拠をレビューアーが設計責務として読み解ける技術を習得
• nullable文化による設計事故をレビュー支援で抑止可能にする

そもそも戻り値nullable設計とは何か

C++では古典的にポインタ型戻り値によるnullable設計が行われてきた。

User* findUser(int userId);

• 存在しない場合はnullptrを返す
• 存在判定は呼び出し側の責務

レビューアーは「nullable許容にした根拠が設計責務として整理されているか？」を常に読み解く必要がある。

なぜこれをレビューするのか

• nullable許容設計が安易に多用され文化事故になる
• 契約粒度が崩壊し保守負荷が肥大化する
• 利用者責務が曖昧になりnull判定漏洩が設計事故源に直結する
• レビュー段階でnullable採用可否を支援整理することが設計品質を大きく左右する

レビューアー視点

• nullableにする根拠が契約責務として説明可能か？
• 契約違反と不在許容の責務が区別整理されているか？
• 呼出側が常にnull判定責務を果たせる文化か？
• nullable濫用でAPI契約粒度が崩壊していないか？
• optional型で型契約化できる設計箇所が放置されていないか？

開発者視点

• nullable採用は「不在が合法である」ことを契約明文化する設計責任
• 契約違反時はnullableに逃げず例外／assertを活用
• optional型が適用可能なら優先検討
• ポインタnullable許容は所有権設計に連動させて利用

良い設計例

例1：契約上合法な不在許容

User* findUser(int userId) {
    if (userId <= 0) {
        throw std::invalid_argument("Invalid user id");
    }
    return db.query(userId); // 見つからない場合nullptr
}

• 入力不正 → 契約違反で例外
• 不在可能性 → nullable許容

例2：nullable採用理由が明文化

// 設計理由: findUserは「存在しない可能性が設計上許容される」
User* findUser(int userId);

• ドキュメント上の契約明示

レビュー観点

• nullable許容が契約設計として合理説明可能か
• 契約違反系はnullableを逃げ道にしていないか
• 呼出側がnullable処理文化を持っているか
• optional型適用整理が未放置になっていないか
• API契約群全体の戻り値粒度が崩壊していないか

良くない実装例: ケース1（契約違反逃げ込み）

User* findUser(int userId) {
    if (userId <= 0) return nullptr;
@Reviewer
契約違反（不正ID）をnullableで逃げています。設計契約は例外で明文化整理してください。
}

改善例

if (userId <= 0) throw std::invalid_argument("Invalid user id");

良くない実装例: ケース2（戻り値粒度崩壊）

User* findUser(int userId);
std::optional<User> findUserSafe(int userId);
@Reviewer
API群内でnullable／optional混在が発生しています。戻り値契約型を統一してください。

改善例

std::optional<User> findUser(int userId);

良くない実装例: ケース3（呼出側責務混乱）

auto user = findUser(123);
process(user->name);
@Reviewer
呼出側がnullable判定責務を果たしていません。必ずnullptr判定責務を設計文化として徹底してください。

改善例

if (user) {
    process(user->name);
}

PlantUML：nullable責務整理図

nullable許容判定フロー

レビューアーはこのフローを即時適用可能に整理する技術力が重要。

ロギング統合例

auto user = findUser(userId);
if (!user) {
    logger.warn("User not found: id={}", userId);
    monitoring.notify("USER_NOT_FOUND");
}

• nullable利用時も通知整理

典型レビュー質問集

レビューアーはnullable設計整理レビュー文化を現場で確立する役割を持つ。

観点チェックリスト

• nullableは契約上の不在許容に限定されているか
• 契約違反は例外で整理されているか
• 呼出側責務が文化として定着しているか
• optional化整理が放置されていないか
• API契約粒度が群内で統一維持されているか
• 通知系統がnullable文化に整合しているか

まとめ

レビューアーがnullable設計レビューで常に問うべきは
「このnullableは契約的に本当に正当な責務整理か？」
です。

• nullable → 許容宣言文化
• 契約違反 → 例外統一文化
• 呼出責務 → 判定責務文化
• 型統一文化 → optional収束文化

レビュー現場では
「nullable採用をレビュー文化で厳格整理する」
ことが現場設計品質を安定化させます。