この記事のポイント

  • 無名namespaceの役割と注意点を整理する
  • レビューでどこを確認すべきかを具体化する
  • 翻訳単位スコープの設計意図をレビューで読み取れる力を身につける

無名namespaceは便利な一方で、設計が崩れ始める起点になりやすい部分でもあります。
レビューアーは、適切な場面でのみ使われているか？ を常に確認する意識が大事です。

1. 無名namespaceとは何か？

1-1. namespaceの基本

通常のnamespaceは、識別子の衝突を防ぐために使います。

namespace Logger {
  void Log(const std::string& msg);
}

名前空間を付けることで、識別子を整理できます。

1-2. 無名namespaceは「このファイル内限定」の仕組み

namespace {
  int internalCounter = 0;
  void helper() { ... }
}
  • 名前空間に名前を付けないことで
  • この翻訳単位（=ソースファイル）だけで有効 という限定スコープが作れます。

1-3. staticと似た「内部リンケージ」

無名namespaceに入れた識別子は、他のソースファイルからは参照できません。

namespace {
  int value = 10;
}

この value は、同じプロジェクト内でも別の翻訳単位からは見えません。

2. 無名namespaceを使う目的

目的 説明
内部実装の隠蔽 外部から見せない仕組み
定数の局所化 翻訳単位ごとに持つ定数
補助的なヘルパー関数 外部公開不要な関数を閉じ込める

✅ 良い使用例（ヘルパー限定化）

namespace {
  void NormalizeString(std::string& text) { ... }
}
  • 外部公開の必要がない関数を閉じ込めるには有効
  • 実装ファイル限定の責務整理に使う

3. 無名namespaceのレビュー対象になる危険なケース

3-1. ヘッダーファイル内で使ってしまう

// ApiRequestLog.h
namespace {
  const int DefaultTimeout = 30;
}

@Reviewer
ヘッダーファイル内での無名namespaceは避けましょう。各翻訳単位に複製されます
  • インクルードされるたびに新しい定義が生成されます

3-2. ODR（One Definition Rule）違反のリスク

// A.cpp
#include "ApiRequestLog.h"

// B.cpp
#include "ApiRequestLog.h"
  • 各翻訳単位で DefaultTimeout が別々に定義される
  • バイナリ上で異なるシンボルになる

4. 無名namespace使用をレビューする時の観点

観点 チェック内容
使用位置 ヘッダーファイルに置かれていないか
使用意図 翻訳単位スコープで合理的か
定数表現 constexprで代替できないか
他翻訳単位影響 ODR違反の温床にならないか
責務整理 無名namespaceの乱用でスコープが崩れていないか

5. 良い実装例：翻訳単位限定の使い方

#pragma once

#include <string>

struct ApiRequestLog {
    int requestId;
    std::string endpoint;
};
// ApiRequestLog.cpp
namespace {
  void NormalizeString(std::string& text) { ... }
}
  • ヘッダーファイルではなく実装ファイルに閉じ込める

6. よくある事故パターン

NG例：ヘッダーファイルに置いてしまう

#pragma once

#include <string>

namespace {
  const int DefaultTimeout = 30;
}

@Reviewer
ヘッダーで無名namespaceを使うと翻訳単位ごとに複製されます。inline constexprを使いましょう

struct ApiRequestLog {
    int requestId;
    std::string endpoint;
};

改善例

#pragma once

#include <string>

inline constexpr int DefaultTimeout = 30;

struct ApiRequestLog {
    int requestId;
    std::string endpoint;
};

定数はinline constexprでヘッダー公開するのが安全です

7. PlantUMLで依存構造を整理

UML Diagram
  • 無名namespaceを Defaults.h に使うと危険
  • Helper.cpp のように実装ファイルで閉じるのが適切

8. CI統制：無名namespaceレビューを自動検出する方法

✅ clang-tidy活用

Checks: '-*,llvm-header-guard,bugprone-anonymous-namespace-in-header'
  • ヘッダーファイル内の無名namespace使用を検出

✅ grepでシンプルに監視

find include/ -name '*.h' | xargs grep 'namespace {'
  • 自作スクリプトでもCIに組み込める

✅ PRレビュー文化の整備

  • 「ヘッダーに無名namespace禁止」をレビュー文化に浸透させる

9. レビュー観点チェックリスト

項目 確認内容
ヘッダーに存在していないか ✅
翻訳単位限定か ✅
定数ならinline constexprで代替できないか ✅
ODR違反リスクが排除できているか ✅
スコープ責務が整理できているか ✅
CIで検出できているか ✅
PRレビューで文化として定着しているか ✅

10. まとめ

無名namespaceは便利ですが、
「使ってよい場所」が非常に限定的です。

  • 実装ファイル内でのみ使う
  • 定数ならinline constexprに整理する
  • 翻訳単位汚染を持ち込まない

レビューアーは構文の是非ではなく
「設計の責務分離が守られているか？」を読み取る
という目線を意識してレビューに臨むのが重要です。