Go言語における有名な格言集（Go Proverbs）は、Rob Pike（ロブ・パイク）が GopherCon 2015 のクロージングキーノートで発表したものです。
単にルールを並べるのではなく、Goのデザイン哲学を短い言葉に凝縮したもので、現在でも開発者の指針となっています。
1. メモリを共有することで通信するな。通信することでメモリを共有せよ
原文
Don't communicate by sharing memory, share memory by communicating.
解説
共有変数を皆で直接いじるより、値を受け渡して連携する考え方です。 状態の責任者をはっきりさせると、競合やロックの悩みが減ります。 「データを渡すことで処理をつなぐ」のがポイントです。
2. 並行性は並列性ではない
原文
Concurrency is not parallelism.
解説
並行性は、仕事を分けて進める設計のことです。 並列性は、実際に同時に動くことです。 goroutine を使っただけで「完全に同時実行」とは限りません。
3. channel は段取りを司り、mutex は直列化する
原文
Channels orchestrate; mutexes serialize.
解説
channel は、値の受け渡しや処理の流れを作る道具です。 mutex は、同時に触らせないように順番待ちさせる道具です。 似て見えても役割はかなり違います。
4. interface は大きいほど抽象として弱くなる
原文
The bigger the interface, the weaker the abstraction.
解説
大きな interface は、実装側に余計な責任まで押しつけやすいです。 小さい interface の方が、役割が明確で差し替えもしやすいです。 「本当に必要な振る舞いだけ」を定義するのが基本です。
5. ゼロ値を有用にせよ
原文
Make the zero value useful.
解説
var x T と書いただけで使える型は、とても扱いやすいです。
初期化忘れによるバグを減らせます。
Go の標準ライブラリも、この考え方をよく採用しています。
6. interface{} は何も語らない
原文
interface{} says nothing.
解説
interface{}（今の any）は何でも入りますが、何を期待しているのか分かりません。
型の意図が見えにくいと、使う側も実装側も困ります。
できるだけ、具体型か小さな interface を使う方が読みやすいです。
7. gofmt のスタイルは誰の一番好みでもないが、皆のお気に入りである
原文
Gofmt's style is no one's favorite, yet gofmt is everyone's favorite.
解説
人ごとの書き方の好みを持ち込まない、という文化です。 見た目の議論を減らして、レビューを中身に集中させられます。 Go では「整形は gofmt に任せる」が強い共通認識です。
8. 少しの依存より少しのコピーの方がよい
原文
A little copying is better than a little dependency.
解説
小さな処理のために、わざわざ外部ライブラリを入れない方がよいことがあります。 依存が増えると、更新・脆弱性・学習コストも増えます。 短く安全な処理なら、自分で書いた方が軽い場合があります。
9. syscall は常に build tags で守らなければならない
原文
Syscall must always be guarded with build tags.
解説
syscall は OS 依存の処理が多いので、対象 OS を限定してビルドする必要があります。
そうしないと、別の OS でビルドしたときに壊れます。
これは 1 ファイルではなく、複数ファイルで学ぶのが自然です。
main.go
pid_linux.go
pid_other.go
実行方法:
10. cgo は常に build tags で守らなければならない
原文
Cgo must always be guarded with build tags.
解説
cgo を使うコードは、cgo が有効な環境でだけ使うのが安全です。 そうしないと、クロスコンパイルや環境差分で詰まりやすくなります。 これも複数ファイルで分けるのが基本です。
main.go
abs_cgo.go
abs_nocgo.go
実行方法:
11. cgo は Go ではない
原文
Cgo is not Go.
解説
cgo を使うと、Go の単純さや移植性が落ちやすくなります。 だから cgo 部分は外から見えないように、境界を薄く閉じ込めるのが大切です。 この格言の本質は「使うな」ではなく、「広げるな」に近いです。
12. unsafe パッケージには保証がない
原文
With the unsafe package there are no guarantees.
解説
unsafe は、Go の安全性の一部を外して触る機能です。
今たまたま動いても、将来まで安全とは限りません。
使うとしても、必要最小限に留めるべきです。
13. 巧妙さより明快さ
原文
Clear is better than clever.
解説
一見かしこそうな書き方より、普通に読めるコードの方が価値があります。 将来の修正やレビューがしやすくなるからです。 自分だけ分かるコードより、他人にも分かるコードを優先します。
14. リフレクションは決して明快ではない
原文
Reflection is never clear.
解説
reflection は柔軟ですが、何が起きているか見えにくくなります。 型安全性も弱く、壊れたときの原因追跡も難しくなりがちです。 普通のコードで書けるなら、まずそちらを優先した方がよいです。
15. エラーは値である
原文
Errors are values.
解説
error は特別な魔法ではなく、普通の値として扱います。 だから、返す・受け取る・包む・比較する、という扱いができます。 Go のエラー処理は、この考え方が土台です。
16. エラーはただチェックするだけでなく、丁寧に扱え
原文
Don't just check errors, handle them gracefully.
解説
err != nil を書くだけでは不十分です。
失敗したときに、続行するのか、代替値を使うのか、中断するのかを考える必要があります。
「どう失敗させるか」も設計の一部です。
17. アーキテクチャを設計し、部品に名前を付け、詳細を文書化せよ
原文
Design the architecture, name the components, document the details.
解説
いきなり実装に入るのではなく、まず全体構造を考えるべきという意味です。 良い名前は、その部品の役割をコード上に残します。 細かい仕様はコメントや文書で補うのが大切です。
18. ドキュメントは利用者のためのもの
原文
Documentation is for users.
解説
コメントやドキュメントは、実装者の独り言ではなく、使う人の助けになるべきです。 何を受け取り、何を返し、どう使うかが分かることが重要です。 「この関数は何のためにあるか」を伝える意識が大切です。
19. panic するな
原文
Don't panic.
解説
普通に起こりうる失敗は、panic ではなく error で返すべきです。 panic は「通常運用で想定しない壊れ方」に近いものです。 回復可能な異常は、呼び出し側に判断を返す方が安全です。