コミュニティデフォルト。 samber/cc-skills-golang@golang-code-style スキルを明示的に上書きするカンパニースキルが優先されます。

Go コードスタイル

人間の判断が必要なスタイルルール — リンターは書式化を扱い、このスキルは明確性を扱います。命名については samber/cc-skills-golang@golang-naming スキルを参照してください。デザインパターンについては samber/cc-skills-golang@golang-design-patterns スキルを参照してください。struct/インターフェース設計については samber/cc-skills-golang@golang-structs-interfaces スキルを参照してください。

"Clear is better than clever." — Go Proverbs

ルールを無視する場合は、コードにコメントを追加してください。

行の長さと折り返し

厳密な行の制限はありませんが、~120 文字を超える行は 必ず 折り返す必要があります。任意の列数ではなく、セマンティックな境界 で折り返します。4 個以上の引数を持つ関数呼び出しは 必ず 1 行に 1 つの引数を使用します — プロンプトがシングルラインコードを要求する場合でも:

// Good — 各引数が独立した行、閉じカッコは別に
mux.HandleFunc("/api/users", func(w http.ResponseWriter, r *http.Request) {
    handleUsers(
        w,
        r,
        serviceName,
        cfg,
        logger,
        authMiddleware,
    )
})

関数シグネチャが長すぎる場合、本当の修正は多くの場合、より良い行の折り返しではなく パラメータを減らす こと (options struct を使用) です。複数行のシグネチャの場合は、各パラメータを独立した行に配置します。

変数宣言

非ゼロ値には := を、ゼロ値の初期化には var を使用する べき です。この形式は意図を示します: var は「これはゼロから始まる」という意味です。

var count int              // ゼロ値、後で設定
name := "default"          // 非ゼロ、:= は適切
var buf bytes.Buffer       // ゼロ値は使用可能

スライスとマップの初期化

スライスとマップは 必ず 明示的に初期化され、nil にはなりません。nil マップは書き込みでパニックします。nil スライスは JSON で null にシリアライズされます (空のスライスの場合は []) — API の利用者を驚かせます。

users := []User{}                       // 常に初期化される
m := map[string]int{}                   // 常に初期化される
users := make([]User, 0, len(ids))      // 容量が既知の場合は事前割り当て
m := make(map[string]int, len(items))   // サイズが既知の場合は事前割り当て

予測的に事前割り当てをしないでください — make([]T, 0, 1000) は一般的なケースが 10 個のアイテムの場合、メモリを無駄にします。

複合リテラル

複合リテラルは 必ず フィールド名を使用する必要があります — 位置フィールドは型がフィールドを追加または並び替えるときに壊れます:

srv := &http.Server{
    Addr:         ":8080",
    ReadTimeout:  5 * time.Second,
    WriteTimeout: 10 * time.Second,
}

制御フロー

ネストを減らす

エラーとエッジケースは 必ず 最初に処理する必要があります (早期リターン)。happy path は最小限のインデントで保ちます:

func process(data []byte) (*Result, error) {
    if len(data) == 0 {
        return nil, errors.New("empty data")
    }

    parsed, err := parse(data)
    if err != nil {
        return nil, fmt.Errorf("parsing: %w", err)
    }

    return transform(parsed), nil
}

不要な else を排除する

if 本体が return/break/continue で終わる場合、else は 必ず 削除される必要があります。単純な代入の場合はデフォルト-その後上書きを使用します — デフォルトを割り当ててから、独立した条件または switch で上書きします:

// Good — デフォルト-その後上書き with switch (相互に排他的な上書きの場合は最も明確)
level := slog.LevelInfo
switch {
case debug:
    level = slog.LevelDebug
case verbose:
    level = slog.LevelWarn
}

// Bad — else-if チェーンはデフォルトがあることを隠す
if debug {
    level = slog.LevelDebug
} else if verbose {
    level = slog.LevelWarn
} else {
    level = slog.LevelInfo
}

複雑な条件と初期化スコープ

if 条件に 3 個以上のオペランドがある場合、名前付きブール値に 必ず 抽出する必要があります — || の壁は読みにくく、ビジネスロジックを隠します。短時間評価の利点を得るために高価なチェックはインラインに保ちます。詳細

// Good — 名前付きブール値は意図を明確にする
isAdmin := user.Role == RoleAdmin
isOwner := resource.OwnerID == user.ID
isPublicVerified := resource.IsPublic && user.IsVerified
if isAdmin || isOwner || isPublicVerified || permissions.Contains(PermOverride) {
    allow()
}

チェックにのみ必要な場合は、変数を if ブロックにスコープします:

if err := validate(input); err != nil {
    return err
}

If-Else チェーンより Switch を優先する

同じ変数を複数回比較する場合は switch を優先します:

switch status {
case StatusActive:
    activate()
case StatusInactive:
    deactivate()
default:
    panic(fmt.Sprintf("unexpected status: %d", status))
}

関数設計

• 関数は 短く、焦点を絞った ものである べき です — 1 つの関数、1 つの仕事。
• 関数は ≤4 パラメータ を持つべき です。それ以上の場合は、options struct を使用します (samber/cc-skills-golang@golang-design-patterns スキルを参照)。
• パラメータの順序: context.Context 最初、その後入力、その後出力宛先。
• ネイキッドリターンは非常に短い関数 (1-3 行) で役立ちます (戻り値は明らかな場合)。しかし、読者が何が返されるかを見つけるためにスクロールする必要があるとき、混乱するようになります — より長い関数では明示的に戻り値に名前を付けます。

func FetchUser(ctx context.Context, id string) (*User, error)
func SendEmail(ctx context.Context, msg EmailMessage) error  // struct にグループ化

イテレーションに range を優先する

インデックスベースのループより range を使用する べき です。単純なカウントには range n (Go 1.22+) を使用します。

for _, user := range users {
    process(user)
}

値対ポインタ引数

小さい型 (string, int, bool, time.Time) は値で渡します。変異させる場合、大きい struct (~128+ バイト) の場合、または nil が意味を持つ場合はポインタを使用します。詳細

ファイル内のコード編成

• 関連する宣言をグループ化: 型、コンストラクタ、メソッドを一緒に
• 順序: パッケージドキュメント、インポート、定数、型、コンストラクタ、メソッド、ヘルパー
• 有意なメソッドを持つ場合は 1 ファイルに 1 つのプライマリ型
• ブランクインポート (_ "pkg") はサイドエフェクト (init 関数) を登録します。それらを main およびテストパッケージに制限することで、サイドエフェクトをライブラリコードで非表示にされるのではなく、アプリケーションルートで表示可能にします
• ドットインポート は名前空間を汚染し、名前がどこから来ているのかを知ることが不可能にします — ライブラリコードでは決して使用しないでください
• 積極的にエクスポートを解除する — いつでも後でエクスポートできます。エクスポートの解除は互換性を破る変更です

文字列処理

単純な変換には strconv を使用し (より高速)、複雑な書式化には fmt.Sprintf を使用します。エラーメッセージで %q を使用して文字列の境界を見えるようにします。ループには strings.Builder を使用し、単純な連結には + を使用します。

型変換

明示的で狭い変換を優先します。具体型が行うジェネリクスを any より優先します:

func Contains[T comparable](slice []T, target T) bool  // not []any

哲学

• "A little copying is better than a little dependency"
• slices および maps 標準パッケージを使用する; filter/group-by/chunk の場合は、github.com/samber/lo を使用します
• "Reflection is never clear" — 必要な場合を除き reflect を避けます
• 過度に抽象化しないでください — パターンが安定しているときに抽出します
• 公開サーフェスを最小化する — すべてのエクスポートされた名前はコミットメントです

コードスタイルレビューの並列化

大規模なコードベース全体でコードスタイルをレビューする場合は、最大 5 つの並列サブエージェント (Agent ツール経由) を使用し、各エージェントは独立したスタイル上の懸念 (例: 制御フロー、関数設計、変数宣言、文字列処理、コード編成) を対象にします。

リンターで実施する

多くのルールは自動的に実施されます: gofmt, gofumpt, goimports, gocritic, revive, wsl_v5。 → samber/cc-skills-golang@golang-lint スキルを参照してください。

クロスリファレンス

• → samber/cc-skills-golang@golang-naming スキルを参照して、識別子の命名規則を確認してください
• → samber/cc-skills-golang@golang-structs-interfaces スキルを参照して、ポインタ対値レシーバー、インターフェース設計を確認してください
• → samber/cc-skills-golang@golang-design-patterns スキルを参照して、関数型オプション、ビルダー、コンストラクタを確認してください
• → samber/cc-skills-golang@golang-lint スキルを参照して、自動書式化実施を確認してください
• → samber/cc-skills-golang@golang-continuous-integration スキルを参照して、これらのガイドラインを使用した CI での AI 駆動コードレビューの自動化を確認してください