C++定数定義はconstexpr／constで明示する｜マジックナンバー排除と設計意図を読み取るレビュー技術
この記事のポイント
- なぜマジックナンバーが危険なのかを整理する
- 定数の意味をレビューで読み取る力を高める
- constexprとconstの使い分けを設計レビュー観点として理解する
定数定義はただ書き方の問題ではありません。
「この値はなぜ固定なのか？ どこで決まったのか？」
これを読み取る力がレビュー品質に直結してきます。
1. なぜ定数がレビュー対象になるのか？
1-1. マジックナンバーとは？
コードに直接数字や文字列が埋め込まれている状態を指します。
if (retryCount > 3) {
// ...
}- 3が何を意味しているのかが分かりにくい
- 同じ値が複数箇所に分散しやすい
- 変更時に意図しない影響を出しやすい
1-2. 設計意図をレビューで読み取る
- 3は仕様値か、実験値か、環境依存なのか
- 変更が前提なのか、固定されるのか
- 定数管理は集中できているのか
レビューアーはこういった背景を確認します。
1-3. 定数化は「意図の可視化」
constexpr int MaxRetryCount = 3;- 値に意味が与えられ、コードが自己説明的になる
- 変更箇所を一元管理できる
- ドメイン知識をコードに埋め込める
2. constexpr と const の違いを整理する
2-1. constexpr：完全固定の定数
- コンパイル時に確定可能な値
- 実行時のコストゼロ
constexpr int BufferSize = 1024;- 定数式で計算できるものに限定
2-2. const：実行時固定の定数
- 実行時に初期化され、その後変更不可
const int RetryLimit = Config::GetDefaultRetryLimit();- 設定ファイルなど外部情報に依存する値などはこちらを使います
2-3. 比較まとめ
| 特性 | constexpr | const |
|---|---|---|
| 決定タイミング | コンパイル時 | 実行時含む |
| 設計意図 | 完全固定 | 実行後は固定 |
| パフォーマンス最適化 | 非常に高い | 状況次第 |
3. レビュー対象として登場する定数の種類
✅ グローバル定数
- APIプロトコルの定義値
- バッファサイズ
- タイムアウト値
✅ クラス内定数
- 状態管理の上限
- ドメイン制約
- 状態遷移定数
✅ 関数内定数
- 局所限定の補助定数
- 可読性のための意味付け
4. 良い実装例：意図が整理された定義
#pragma once
#include <string>
struct ApiRequestLog {
int requestId;
std::string endpoint;
std::string clientIp;
};
inline constexpr int DefaultTimeoutSeconds = 30;
inline constexpr size_t MaxRequestSize = 8192;設計意図
- API設計でドメイン知識を明示している
- ヘッダー共有用に inline constexpr を採用
- ODR（One Definition Rule）安全性を確保している
5. 良くない実装例とレビュー訓練
ケース1：マジックナンバーの埋め込み
void HandleRequest() {
if (requestSize > 8192) {
Reject();
}
}
@Reviewerマジックナンバーが埋め込まれています。意味付けされた定数名にしてください
改善例
inline constexpr size_t MaxRequestSize = 8192;
void HandleRequest() {
if (requestSize > MaxRequestSize) {
Reject();
}
}6. 無名namespaceでの定数宣言の誤り
NGパターン（旧来のstatic代用）
namespace {
const int DefaultTimeoutSeconds = 30;
}
@ReviewerC++11以降はinline constexprの使用が推奨されます
改善例
inline constexpr int DefaultTimeoutSeconds = 30;7. PlantUMLで依存構造を整理
- 定数専用ヘッダーで依存を整理
- スコープ整理もレビューの重要ポイント
8. CI統制：レビュー品質を維持する仕組み
✅ clang-tidy を活用
Checks: '-*,readability-magic-numbers'- マジックナンバー自動検出に利用
✅ PRレビュー文化を育てる
- 定数名の意味付けができているか
- マジックナンバーが残っていないか
✅ テンプレート化でミス防止
- 新規ファイル作成時に定数ヘッダーの雛形を配布
9. レビュー観点チェックリスト
| 観点 | 確認ポイント |
|---|---|
| マジックナンバー排除 | 裸の数字が残っていないか |
| constexpr活用 | コンパイル時決定可能ならconstexprにしているか |
| const適用 | 実行時計算はconstで固定されているか |
| inline constexpr | ヘッダー共有時のODR安全性が確保されているか |
| スコープ整理 | 定数管理の責任範囲が整理できているか |
| 無名namespace排除 | 無名namespaceで定数管理していないか |
| CI統制 | 自動検出ルールがCIに組み込まれているか |
| PRレビュー文化 | 意図の見える命名が徹底されているか |
10. まとめ
定数設計は、「設計意図をコードに刻む作業」 でもあります。
レビューアーは次の問いを常に確認しておくと読み取りやすくなります。
- この値はなぜ固定なのか？
- 誰が変更する責任を持つのか？
- ドメイン知識が読み取れる状態になっているか？
マジックナンバーを消すだけで終わらず、
「設計を読み取るレビュー」を意識していきたいところです。