コミュニティデフォルト。 samber/cc-skills-golang@golang-naming スキルを明示的に置き換える会社スキルが優先されます。

Go 命名規則

Go は簡潔で読みやすい名前を推奨します。大文字小文字は可視性を制御します — 大文字はエクスポート、小文字はアンエクスポートです。すべての識別子は MixedCaps を使用する必要があり、アンダースコアは使用しません。

"明確さは賢さよりも優れている。" — Go Proverbs

"アーキテクチャを設計し、コンポーネントに名前を付け、詳細を文書化しなさい。" — Go Proverbs

ルールを無視するには、コードにコメントを追加するだけです。

クイックリファレンス

要素	規則	例
パッケージ	小文字、1 語、テストファイルの場合 _test サフィックス OK	json、http、tabwriter、http_test
ファイル	小文字、アンダースコア OK	user_handler.go
エクスポート名	UpperCamelCase	ReadAll、HTTPClient
アンエクスポート	lowerCamelCase	parseToken、userCount
Interface	メソッド名 + -er	Reader、Closer、Stringer
Struct	MixedCaps 名詞	Request、FileHeader
定数	MixedCaps（ALL_CAPS ではない）	MaxRetries、defaultTimeout
Receiver	1～2 文字の短縮形	func (s *Server)、func (b *Buffer)
エラー変数	Err プレフィックス	ErrNotFound、ErrTimeout
エラー型	Error サフィックス	PathError、SyntaxError
コンストラクタ	New（単一型）または NewTypeName（複数型）	ring.New、http.NewRequest
Boolean フィールド	フィールドとメソッドに is、has、can プレフィックス	isReady、IsConnected()
テスト関数	Test + 関数名	TestParseToken
頭字語	すべて大文字またはすべて小文字	URL、HTTPServer、xmlParser
バリアント: context	WithContext サフィックス	FetchWithContext、QueryContext
バリアント: インプレース	In サフィックス	SortIn()、ReverseIn()
バリアント: エラー	Must プレフィックス	MustParse()、MustLoadConfig()
Option func	With + フィールド名	WithPort()、WithLogger()
Enum (iota)	型名プレフィックス、ゼロ値 = 不明	iota 0 で StatusUnknown、StatusReady
名前付きリターン	説明的（ドキュメント用のみ）	(n int, err error)
エラー文字列	小文字（頭字語含む）、句読点なし	"image: unknown format"、"invalid id"
インポートエイリアス	短い、衝突時のみ	mrand "math/rand"、pb "app/proto"
Format 関数	f サフィックス	Errorf、Wrapf、Logf
テストテーブルフィールド	got/expected プレフィックス	input string、expected int

MixedCaps

すべての Go 識別子は MixedCaps（または mixedCaps）を使用する必要があります。識別子にアンダースコアは使用しません — 唯一の例外はテスト関数のサブケース（TestFoo_InvalidInput）、生成されたコード、および OS/cgo 相互運用です。これは見た目の問題ではなく、機能に関わります — Go のエクスポート機構は大文字小文字に依存し、ツールは全体で MixedCaps を想定しています。

// ✓ Good
MaxPacketSize
userCount
parseHTTPResponse

// ✗ Bad — これらの規則は Go のエクスポート機構とツールの期待に矛盾します
MAX_PACKET_SIZE   // C/Python スタイル
max_packet_size   // snake_case
kMaxBufferSize    // ハンガリアン記法

スタッタリングを避ける

Go のコールサイトは常にパッケージ名を含むため、識別子でそれを繰り返すと読み手の時間を浪費します — http.HTTPClient は「HTTP」を 2 回解析させます。名前は、パッケージ名、型名、または周囲のコンテキストに既に存在する情報を繰り返してはいけません。

// Good — コールサイトがクリーン
http.Client       // not http.HTTPClient
json.Decoder      // not json.JSONDecoder
user.New()        // not user.NewUser()
config.Parse()    // not config.ParseConfig()

// In package sqldb:
type Connection struct{}  // DBConnection ではなく — "db" は既にパッケージ名にある

// アンチスタッター は主要な struct だけでなく、すべてのエクスポート型に適用されます：
// In package dbpool:
type Pool struct{}        // DBPool ではなく
type Status struct{}      // PoolStatus ではなく — 呼び出し元は dbpool.Status と記述
type Option func(*Pool)   // PoolOption ではなく

よく見落とされる規則

これらの規則は正しいですが非明白です — 命名の誤りの最も一般的な原因です：

コンストラクタ命名： パッケージが単一の主要型をエクスポートする場合、コンストラクタは New()（NewTypeName() ではない）です。これはスタッタリングを避けます — 呼び出し元は apiclient.New() と書き、apiclient.NewClient() ではありません。複数の構築可能な型を持つパッケージの場合（http.NewRequest、http.NewServeMux など）のみ NewTypeName() を使用します。

Boolean struct フィールド： アンエクスポートの boolean フィールドは is/has/can プレフィックスを使用する必要があります — isConnected、hasPermission（裸の connected または permission ではない）。エクスポートされたゲッターはプレフィックスを保持します：IsConnected() bool。これは質問として自然に読め、boolean を他の型と区別します。

エラー文字列は完全に小文字です — 頭字語を含めて。 "invalid message ID" ではなく "invalid message id" と書いてください。エラー文字列は他のコンテキストと連結されることが多く（fmt.Errorf("parsing token: %w", err)）、大文字小文字が混在していると文中に見えるためです。センチネルエラーはプレフィックスとしてパッケージ名を含める必要があります：errors.New("apiclient: not found")。

Enum ゼロ値： iota 位置 0 に明示的な Unknown/Invalid センチネルを常に配置します。var s Status は静かに 0 になります — それが StatusReady のような実際の状態にマップされる場合、意図的に選択されたかのようにコードが動作することがあります。

Subtest 名： t.Run() のテーブル駆動型テストケース名は完全に小文字の説明句である必要があります："valid id"、"empty input" — "valid ID" または "Valid Input" ではなく。

詳細カテゴリー

完全なルール、例、および根拠については、以下を参照してください：

• Packages, Files & Import Aliasing — パッケージ命名（1 語、小文字、複数形なし）、ファイル命名規則、インポートエイリアスパターン（認知負荷を避けるため衝突時のみ使用）、ディレクトリ構造。

• Variables, Booleans, Receivers & Acronyms — スコープベースの命名（名前の長さはスコープと一致：3 行ループでは i、パッケージレベルではより長い名前）、1 文字の receiver 規則（s for Server）、頭字語大文字小文字（Url ではなく URL、HttpServer ではなく HTTPServer）、boolean 命名パターン（isReady、hasPrefix）。

• Functions, Methods & Options — Getter/setter パターン（Go は Get を省略するため user.Name() は自然に読める）、コンストラクタ規則（New または NewTypeName）、名前付きリターン（ドキュメント用のみ）、format 関数サフィックス（Errorf、Wrapf）、functional options（WithPort、WithLogger）。

• Types, Constants & Errors — Interface 命名（Reader、Closer サフィックスと -er）、struct 命名（名詞、MixedCaps）、定数（MixedCaps、ALL_CAPS ではない）、enum（StatusReady のような型名プレフィックス）、センチネルエラー（ErrNotFound 変数）、エラー型（PathError サフィックス）、エラーメッセージ規則（小文字、句読点なし）。

• Test Naming — テスト関数命名（TestFunctionName）、テーブル駆動型テストフィールド規則（input、expected）、テストヘルパー命名、サブケース命名パターン。

よくある誤り

誤り	修正
ALL_CAPS 定数	Go は可視性のために大文字小文字を予約し、強調のためではありません — MixedCaps（MaxRetries）を使用します
GetName() ゲッター	Go は Get を省略します。なぜなら user.Name() はコールサイトで自然に読めるからです。ただし Is/Has/Can プレフィックスは boolean 述語で保持されます：Healthy() bool ではなく IsHealthy() bool
Url、Http、Json 頭字語	大文字小文字混在の頭字語は曖昧さを生じます（HttpsUrl — Https+Url ですか？）。すべて大文字またはすべて小文字を使用します
this または self receiver	Go メソッドは頻繁に呼び出されます — 視覚的ノイズを減らすために 1～2 文字の短縮形（Server の場合 s）を使用します
util、helper パッケージ	これらの名前はコンテンツについて何も述べません — 抽象化を説明する具体的な名前を使用します
http.HTTPClient スタッタリング	パッケージ名は常にコールサイトに存在します — http.Client は「HTTP」を 2 回読むのを避けます
user.NewUser() コンストラクタ	単一の主要型は New() を使用します — user.New() は型名の繰り返しを避けます
connected bool フィールド	裸の形容詞は曖昧です — isConnected を使用してフィールドが true/false の質問として読めるようにします
"invalid message ID" エラー	エラー文字列は頭字語を含めて完全に小文字である必要があります — "invalid message id"
iota 0 での StatusReady	ゼロ値はセンチネルである必要があります — StatusUnknown at 0 は未初期化値をキャッチします
"not found" エラー文字列	センチネルエラーはパッケージ名をプレフィックスとして含む必要があります — "mypackage: not found" は起源を識別します
userSlice 型名	型は実装の詳細をエンコードします — users は保持内容を説明し、方法ではありません
一貫性のない receiver 名	同じ型のメソッド間で名前を切り替えると読者を混乱させます — 1 つの名前を一貫して使用します
snake_case 識別子	アンダースコアは Go の MixedCaps 規則とツールの期待に矛盾します — mixedCaps を使用します
短いスコープでの長い名前	名前の長さはスコープと一致する必要があります — i は 3 行ループで問題ありませんが、userIndex はノイズです
値で定数に名前を付ける	値は変わりますが、役割は変わりません — DefaultPort はポート変更後も機能しますが、Port8080 は機能しません
FetchCtx() context バリアント	WithContext は標準的な Go サフィックスです — FetchWithContext() は瞬時に認識できます
sort() インプレースだが In なし	読者は関数が新しい値を返すと想定します。SortIn() は変更を通知します
parse() エラーをパニック	MustParse() は失敗がパニックすることを呼び出し元に警告します — 驚きは名前に属します
With*、Set*、Use* を混在	コードベース全体で一貫性を — With* は functional options の Go 規則です
複数形のパッケージ名	Go 規則は単数です（net/urls ではなく net/url） — インポートパスを一貫性に保ちます
f サフィックスなしの Wrapf	f サフィックスは format-string セマンティクスを通知します — Wrapf、Errorf は呼び出し元に format 引数を渡すことを伝えます
不要なインポートエイリアス	エイリアスは認知負荷を追加します。衝突時のみエイリアス — mrand "math/rand"
概念名の一貫性がない	user/account/person を同じコンセプトに使用すると読者はシノニムを追跡させられます — 1 つの名前を選びます

Linter で強制

多くの命名規則の問題は自動的に linter によってキャッチされます：revive、predeclared、misspell、errname。設定と使用については samber/cc-skills-golang@golang-lint スキルを参照してください。

クロスリファレンス

• → より広い形式とスタイル決定については samber/cc-skills-golang@golang-code-style スキルを参照
• → interface 命名の深さと receiver 設計については samber/cc-skills-golang@golang-structs-interfaces スキルを参照
• → 自動強制（revive、predeclared、misspell、errname）については samber/cc-skills-golang@golang-lint スキルを参照