よくある間違い

Go 言語げんごの一般的いっぱんてきな間違まちがいとベストプラクティス。

Link: GitHub Pseudo Code

1. Unintended variable shadowing

変数へんすうシャドウイング

変数へんすうが内部ないぶブロックで再宣言さいせんげんされると、間違まちがった変数へんすうを参照さんしょうしてエラーや混乱こんらんを引ひき起おこす可能性かのうせいがある。混乱こんらんを防ふせぐために同おなじ名前なまえの変数へんすうは避さけるべき。

2. Unnecessary nested code

不必要ふひつようなネスト

過度かどなネストはコードの理解りかいを困難こんなんにする。「happy path」を左側ひだりがわに保たもち、早期そうきリターンでネストを減へらすべき。if-else での else を避さけ、条件じょうけんを満みたさない場合ばあいは直接ちょくせつリターンする。

3. Misusing init functions

init 関数かんすうは初期化しょきかに使用しようされるが、エラー処理しょりが限定的げんていてきで、状態じょうたい管理かんりやテストを複雑ふくざつにする可能性かのうせいがある。初期化しょきかは専用せんようの関数かんすうで処理しょりし、グローバル変数へんすうと不要ふような依存いぞん関係かんけいを避さけるべき。

4. Overusing getters and setters

Go では Getter と Setter の強制きょうせい使用しようは慣例かんれいではない。価値かちを追加ついかしないなら使用しようすべきではない。Go はシンプルな設計せっけいを推奨すいしょうし、効率こうりつとプログラミング慣習かんしゅうのバランスを取とるべき。

5. Interface pollution

インターフェース汚染おせん

不必要ふひつような抽象ちゅうしょうインターフェースを事前じぜんに作成さくせいすべきではなく、本当ほんとうに必要ひつような時ときにのみ作成さくせいし、複雑ふくざつさを避さけるべき。良よい抽象ちゅうしょうは強制きょうせいされるのではなく発見はっけんされるべき。

6. Interface on the producer side

Go ではインターフェースの実装じっそうは暗黙的あんもくてきであり、通常つうじょうはコンシューマーがインターフェースが必要ひつようかどうかを決定けっていすべきで、プロデューサーが抽象ちゅうしょうを強制きょうせいすべきではない。プロデューサーがインターフェースを提供<rt ていきょうする必要ひつようがある場合ばあいは、再利用性さいりようせいと組くみ合あわせ性せいを高たかめるために最小限さいしょうげんに保たもつべき。

7. Returning interfaces

accept interfaces, return structs

関数かんすうはインターフェースではなく具体的ぐたいてきな型かたを返かえすべき
関数かんすうは引数ひきすうとしてインターフェースを受うけ取とるべき

8. any says nothing

any は本当ほんとうに任意にんいの型かたを受うけ入いれたり返かえしたりする必要ひつようがある場合ばあいにのみ使用しよう（例：json.Marshal）
any の不適切ふてきせつな使用しようのデメリット：
- 意味いみのある型かた情報じょうほうを提供ていきょうできない
- コンパイル時じの問題もんだいを引ひき起おこす可能性かのうせい
- 呼よび出だし元もとが任意にんいの型かたのデータを使用しよう可能かのう
過度かどな汎用化はんようかを避さける
適度てきどなコードの重複じゅうふくは any を使用しようするより良よい場合ばあいがある
any を使用しようする前まえに本当ほんとうに任意にんいの型かたを処理しょりする必要ひつようがあるか評価ひょうかすべき

9. Being confused about when to use generics

ジェネリクスを使つかわない方ほうが良よい場合ばあい

型かたパラメータのメソッドを呼よび出だすだけの場合ばあい

// Not Good: ジェネリクス不要、interface を直接使用
func foo[T io.Writer](w T) {
    b := getBytes()
    _, _ = w.Write(b)
}

// Good: interface を直接使用
func foo(w io.Writer) {
    b := getBytes()
    _, _ = w.Write(b)
}

コードを複雑ふくざつにする場合ばあい

// Not Good: 過度な抽象化
func doSomething[T any](item T) T {
    return item
}

ジェネリクスを使つかうべき場合ばあい

汎用はんようデータ構造こうぞう

// Good: ジェネリックデータ構造
type Node[T any] struct {
    Val  T
    next *Node[T]
}

func (n *Node[T]) Add(next *Node[T]) {
    n.next = next
}

slice, map, channel などの汎用はんよう型かたを処理しょりする場合ばあい

// Good: 任意の型の channel をマージ
func merge[T any](ch1, ch2 <-chan T) <-chan T {
    // implementation
}

// Good: 任意の型の map の keys を取得
func getKeys[K comparable, V any](m map[K]V) []K {
    var keys []K
    for k := range m {
        keys = append(keys, k)
    }
    return keys
}

動作どうさパターンを抽象化ちゅうしょうかする場合ばあい

// Good: 汎用ソート動作
type sliceFn[T any] struct {
    s       []T
    compare func(T, T) bool
}

func (s sliceFn[T]) Len() int           { return len(s.s) }
func (s sliceFn[T]) Less(i, j int) bool { return s.compare(s.s[i], s.s[j]) }
func (s sliceFn[T]) Swap(i, j int)      { s.s[i], s.s[j] = s.s[j], s.s[i] }

10. Not being aware of the possible problems with type embedding

Issue 1: シンプルな Embedding

シンタックスシュガーのためだけに使用しよう（foo.Baz vs foo.Bar.Baz）
「アクセスを簡略化かんりゃくかするためだけに embedding を使用しようすべきではない」という原則げんそくに違反いはん

type Foo struct {
    Bar
}
type Bar struct {
    Baz int
}

Issue 2: Mutex Embedding

同期どうきメカニズム（Lock/Unlock メソッド）が公開こうかいされる
クライアントがロックを直接ちょくせつ操作そうさでき、カプセル化かが破壊はかいされる
埋うめ込こみではなくコンポジションを使用しようすべき

// 非推奨
type InMem struct {
    sync.Mutex
    m map[string]int
}

// 推奨
type InMem struct {
    mu   sync.Mutex
    data map[string]string
}

Issue 3: コンストラクタとレシーバ

より説明的せつめいてきな命名めいめい（writer vs writeCloser）
コンストラクタを追加ついか
ポインタレシーバを使用しよう

type Logger struct {
    writer io.WriteCloser
}

// 推奨：Pointer Receiver
func (l *Logger) Write(p []byte) (int, error) {
    return l.writer.Write(p)
}

func (l *Logger) Close() error {
    return l.writer.Close()
}

プロジェクト構造