命名規則は何を基準にレビューすべきか？Go的なベストプラクティス

命名は、コードの意味を言語化する行為であり、設計意図をレビューアーが読み解く最初のヒントとなる。
Go言語では命名規則が明文化されていない反面、標準ライブラリに倣った慣習的なスタイルが広く共有されている。
この記事では、Goらしい命名と逸脱事例を通じて、レビューアーが命名からどこまで設計を読み取るべきかを整理する。

1. 命名が示す“構造的意図”を理解する

まずは、命名が適切に構造・責務と一致している理想的な例を見てみよう。

// AuthService is responsible for user authentication.
type AuthService interface {
    Authenticate(email, password string) (User, error)
}

// JWTGenerator creates signed JWT tokens.
type JWTGenerator interface {
    GenerateToken(user User) (string, error)
}

これらの命名は、インターフェースの責務が名前から一貫して明示されている好例である。
関数名も動詞 + 名詞の構造で、英語としても自然であり、処理内容を端的に表現できている。

名前から「何をするか」「何を返すか」「どう使われるか」が明確であれば、初見でも構造理解の助けになる。

このようなコードに対してはレビューコメントは不要であり、構造理解の足場として読み手の認知負荷を大きく下げている点に注目したい。

2. 問題例：命名から構造が読み取れない場合

次に、命名が設計意図とズレてしまっている例を提示し、それに対するレビューアーの視点での指摘を整理する。

type Service interface {
    Do(ctx context.Context) error
}

@Reviewer
このインターフェース名とメソッド名から責務が一切読み取れません。具体的な業務内容が分かるよう `EmailSender` や `NotifyUser` などに変更してください。


func SaveOrUpdateOrDeleteUser(u User) error

@Reviewer
複数の責務が1つの関数に混在しています。処理の分岐に応じて関数を分割し、命名にも責務が反映されるよう整理しましょう。


type api struct{}

@Reviewer
英単語としてあまりに曖昧です。`UserAPI` や `NotificationAPI` など、対象領域を明示する命名にしましょう。

命名が曖昧な場合、利用側コードも読解が困難になります。責務の明示は“自分以外の開発者が読む”という前提で行うべきです。

3. 「良い命名」に共通する構造的特徴

以下のような特徴を備える命名は、レビューアーからも評価されやすい。

  • 単語の順序が英語的に自然（例：UserService、TokenManager）
  • 名詞・動詞の使い分けが明確（例：GenerateToken()は副作用あり、Token()は値取得）
  • 略語の取り扱いが標準ライブラリと整合（例：UserID、BaseURL、HTTPClient）
  • 可視性（export/unexport）と意味が一致（大文字で公開、小文字で内部専用）

以下は良い構造例である：

// Logger provides logging capability per request.
type Logger interface {
    Info(msg string)
    Error(err error)
}

// RedisStore handles caching logic.
type RedisStore struct {
    client *redis.Client
}

命名の粒度と責務の粒度が一致していることが、構造的に優れた設計を支えている。

4. 命名に見る“アンチパターン”とその指摘

✕ 名前と返却値が一致しない

func GetUser() bool

@Reviewer
関数名と返却値の型が一致していません。`IsUserExists()` のように意図を表現する命名に変更しましょう。

✕ 言語として不自然・直訳的

func DoPostData()

@Reviewer
`DoPostData` は意味不明瞭かつ直訳調です。`PostData` のように主語と動詞の順に整理してください。

✕ ドメインが分からない

type Controller interface {
    Handle(ctx context.Context) error
}

@Reviewer
ドメインが不明な命名は避けてください。例えば `UserController` や `SessionController` など、範囲を明確にした名前にしましょう。

5. 命名レビューにおけるチェックシート

以下のチェックリストは、レビュー時の確認用として活用できる。

観点 チェック内容
命名の明確性 名称から機能や責務が読み取れるか
可視性との整合 export/unexportの意図が一致しているか
英語の自然さ 英語表現として不自然でないか
略語の一貫性 Goの慣習（ID, URL等）に従っているか
責務の分離 名前に複数責務が埋め込まれていないか

命名から読み取れる“粒度”と“範囲”が、設計の分解単位と一致しているかをレビュー時に確認してください。

あとがき：命名は「実装」ではなく「設計」の一部

Goの命名規則は、表面的にはルールが少ないように見えるかもしれない。
しかし、標準ライブラリに共通する“粒度感”や“構造との一致”は、確かな暗黙知として共有されている。

レビューアーは命名だけを評価するのではなく、命名から逆に構造を復元し、設計意図を読み解く必要がある。
命名は“記述”ではなく“翻訳”であり、設計の意味が読み手に正しく伝わるかを判断軸とすることが、レビューの本質となる。

::: この記事ではあえて「良い命名の例 → 問題例 → 指摘コメント → チェックリスト → 要点整理」という構成にした。
レビューアーとしての筋力をつけるために、日頃から「名前を手がかりに設計を読み解く」練習を重ねてほしい。 :::