● Goコードレビューでよく指摘されるやつ

https://go.dev/wiki/CodeReviewComments

Goコードレビューでよく指摘される項目のチートシート。網羅的なスタイルガイドではなく、レビューで頻出するコメントの早見表。

フォーマット・コメント

• Gofmt: 機械的なスタイルはgofmt(またはgoimports)に任せる
• コメント文: エクスポートする宣言のコメントは完全な文で。名前から始めてピリオドで終える
• Docコメント: トップレベルのエクスポート名には必ず付ける
• パッケージコメント: package宣言の直前、空行なしで書く

命名規則

• Mixed Caps: MAX_LENGTHではなくmaxLength
• 頭字語: URL/IDは大文字小文字を統一（UrlはNG）
• 変数名: スコープが狭いほど短く(lineCountよりc)。宣言から離れるほど説明的に
• レシーバ名: 型の1〜2文字の略称。self/thisのような汎用名は避ける
• パッケージ名: util/commonなど無意味な名前を避ける

エラー処理

• エラーは握りつぶさない: _で無視しない
• エラー文字列: 大文字で始めない、句読点で終えない
• 正常系を先に: エラー処理を先に片付け、正常系のインデントを浅く保つ
• バンド内エラー禁止: -1やnilではなく(value, ok)や(value, err)の複数戻り値で表現
• panicを使わない: 通常のエラー処理には使わない

設計・API

• Context: 第一引数として明示的に渡す。構造体フィールドにしない
• インターフェース: 利用側パッケージに定義する。モック目的だけの定義はしない
• 名前付き戻り値: godocでの見え方を考え、本当に必要な時だけ使う
• ポインタは節約目的で使わない: サイズが変わらない値をポインタにしない
• 値/ポインタレシーバ: 迷ったらポインタ。ミューテックスを含む構造体は必ずポインタ
• 同期関数を優先: 非同期より同期関数の方がテストしやすく安全

その他

• コピー注意: ポインタ型にメソッドが紐づく型はコピーしない
• 乱数: キー生成にmath/randは使わずcrypto/randを使う
• 空スライス: []string{}よりvar t []string(nil)を優先
• Goroutineの寿命: いつ終了するか明確にする
• 行の長さ: 厳密な制限はなく、意味的な理由で改行する
• テスト失敗メッセージ: got != wantの順でわかりやすく出力する

参考 : Go の interface は構造体の利用側が定義すると言う話 – もばらぶエンジニアブログ