Go スタイルコア原則

スタイル原則（優先度順）

読みやすい Go コードを書く際は、以下の原則を優先度順に適用します：

優先度順

1. 明確性（Clarity） — 読み手が余計な背景知識なしにコードを理解できるか？
2. シンプルさ（Simplicity） — これが目標を達成するもっともシンプルな方法か？
3. 簡潔性（Concision） — すべての行が存在価値を持っているか？
4. 保守性（Maintainability） — 後で変更しやすいか？
5. 一貫性（Consistency） — 周囲のコードやプロジェクト規約に合致しているか？

明確性、シンプルさ、簡潔性の間の葛藤を解決する際、またはそれぞれの原則が実際の Go コードでどのように適用されるかを知りたい際は、references/PRINCIPLES.md を参照してください。

---

フォーマット

gofmt を実行してください — 例外なしです。厳密な行の長さ制限はありません が、Uber は 99 文字のソフトリミットを推奨しています。長さではなく意味で改行を判断し、単に折り返すのではなくリファクタリングしてください。

gofmt の設定、行区切りの判断、MixedCaps ルールの適用、またはローカルな一貫性の問題を解決する際は、references/FORMATTING.md を参照してください。

---

ネストを減らす

エラーケースと特殊な条件を最初に処理します。早期に return するか loop を continue させることで、「正常系（happy path）」を字下げしないままにします。

// 悪い例：深くネストしている
for _, v := range data {
    if v.F1 == 1 {
        v = process(v)
        if err := v.Call(); err == nil {
            v.Send()
        } else {
            return err
        }
    } else {
        log.Printf("Invalid v: %v", v)
    }
}

// 良い例：早期 return でフラットな構造
for _, v := range data {
    if v.F1 != 1 {
        log.Printf("Invalid v: %v", v)
        continue
    }

    v = process(v)
    if err := v.Call(); err != nil {
        return err
    }
    v.Send()
}

不要な Else

if の両方の分岐で変数が設定される場合は、デフォルト値＋上書きパターンを使用します。

// 悪い例：両方の分岐で設定
var a int
if b {
    a = 100
} else {
    a = 10
}

// 良い例：デフォルト値 + 上書き
a := 10
if b {
    a = 100
}

---

Naked Returns

引数を指定しない return ステートメントは、名前付き戻り値を返します。これは「naked return」として知られています。

func split(sum int) (x, y int) {
    x = sum * 4 / 9
    y = sum - x
    return // x, y を返す
}

Naked Returns のガイドライン

• 小さな関数では OK：Naked return は数行程度の関数では問題ありません
• 中程度以上の関数では明示的に：関数が中程度のサイズに成長したら、明確性のため戻り値を明示的に書きます
• Naked return のためだけに結果を名前付けしない：ドキュメント化の明確性は、1〜2 行を節約することより常に重要です

// 良い例：小さな関数、naked return は明確
func minMax(a, b int) (min, max int) {
    if a < b {
        min, max = a, b
    } else {
        min, max = b, a
    }
    return
}

// 良い例：大きな関数、明示的な return
func processData(data []byte) (result []byte, err error) {
    result = make([]byte, 0, len(data))

    for _, b := range data {
        if b == 0 {
            return nil, errors.New("null byte in data")
        }
        result = append(result, transform(b))
    }

    return result, nil // 明示的：長い関数ではより明確
}

名前付き戻り値パラメータのガイダンスは go-documentation を参照してください。

---

セミコロン

Go の字句解析器は、最後のトークンが識別子、リテラル、または break continue fallthrough return ++ -- ) } のいずれかである行の後に自動的にセミコロンを挿入します。

これは、開き括弧は制御構造と同じ行になければならない ことを意味します：

// 良い例：括弧が同じ行
if i < f() {
    g()
}

// 悪い例：括弧が次の行 — 字句解析器が f() の後にセミコロンを挿入
if i < f()  // 間違い！
{           // 間違い！
    g()
}

慣用的な Go では、セミコロンは for loop の句内と、1 行に複数のステートメントを並べるときだけ明示的に使用されます。

---

クイックリファレンス

原則	キーとなる質問
明確性	読み手が何と なぜを理解できるか？
シンプルさ	これが最もシンプルなアプローチか？
簡潔性	シグナルノイズ比は高いか？
保守性	これを後で安全に変更できるか？
一貫性	これは周囲のコードと合致しているか？

関連スキル

• 命名規則：MixedCaps の適用、識別子名の選択、命名に関する議論を解決する際は go-naming を参照してください
• エラー処理フロー：エラーファーストガード句の構造化や early return によるネスト削減は go-error-handling を参照してください
• ドキュメント：doc コメント、名前付き戻り値パラメータ、パッケージレベルドキュメントを書く際は go-documentation を参照してください
• Linting 自動化：golangci-lint によるスタイルチェックの自動化や CI 設定は go-linting を参照してください
• コードレビュー：体系的なコードレビュー中にスタイル原則を適用する際は go-code-review を参照してください
• ロギングスタイル：ロギング慣行の確認、log と slog の選択、ログ出力の構造化は go-logging を参照してください