意見のあるツール — gofmt、gofumpt とコードスタイルの政治学

はじめに — 再び浮上したフォーマッタ論争
自動フォーマットの哲学 — 論争を終わらせるためのツール
gofmt の誕生 — Go 初期の決断
gofmt — 標準になったフォーマッタ
gofumpt — gofmt よりもう一歩
gofumpt のルールをさらに深く見る
goimports — フォーマットと import 管理の結合
エディタ統合 — 保存すれば自動で整う体験
他言語との比較 — prettier、black、rustfmt
設定可能性のスペクトル — dprint、Biome、clang-format、EditorConfig
リントとフォーマットは違う
フォーマッタが手をつけないもの — 限界と例外
チームの合意と CI 強制 — ツールをルールにする
意見のあるツールの長所と短所
- 長所
- 短所と批判
実戦事例 — 大規模コードベースに初めてフォーマッタを導入する
実務適用ガイド
おわりに
参考資料

はじめに — 再び浮上したフォーマッタ論争

最近 GeekNews で gofumpt に関する記事が再び話題になりました。「gofmt だけでは足りない」としてより厳格なルールを適用するこのフォーマッタをめぐり、意見のあるツール(opinionated tooling)がどこまで強制してよいのかという論争が再び燃え上がったのです。

興味深いのは、この論争が単なる好みの争いではないことです。インデントをタブにするかスペースにするか、波括弧をどこに置くかといった些細に見える決定は、実はチームの時間と感情を驚くほど多く消費してきました。Go 陣営はこの問題を gofmt というたったひとつのツールで片づけてしまい、その決断は今も他言語のエコシステムが羨むモデルとして残っています。

本記事では、自動フォーマットの哲学から出発し、gofmt とより厳格な gofumpt を比較し、prettier や black など他言語のツールと突き合わせます。そして意見のあるツールがチームの合意と CI にどう溶け込むか、その長所と短所は何かを深く見ていきます。

自動フォーマットの哲学 — 論争を終わらせるためのツール

コードスタイル論争はソフトウェアの歴史と同じくらい古いものです。そしてその論争の大半は正解のない好みの問題でした。どちらでも一貫性さえあればコードはちゃんと動きます。それでも人々はこの些細な違いについて延々と論争してきました。

Go 言語設計者の洞察はここにありました。「スタイルに正解はない。だから論争そのものをなくそう」。gofmt は正しいスタイルを強制するためのツールではなく、スタイルについての論争を終わらせるためのツールです。どのスタイルかは重要ではありません。全員が同じスタイルを使うという事実が重要なのです。

この哲学は一文で要約されます。「Gofmt's style is no one's favorite, yet gofmt is everyone's favorite.」誰も gofmt のスタイルを最も好むわけではないが、全員が gofmt を最も好む、という意味です。

// 作者がどう書いても
func   add(a int,b int)int{return a+b}

// gofmt を通せば常に同じ形になる
func add(a int, b int) int {
	return a + b
}

核心は「選択肢をなくす」ことにあります。選択肢がなければ論争の種もありません。そして論争がなければそのエネルギーを実際の問題解決に注げます。

gofmt の誕生 — Go 初期の決断

この哲学が単なるスローガンではなくツールとして実装された背景には、Go 言語初期の決断がありました。Go は 2009 年の公開時から gofmt を一緒に携えて登場しました。言語が世に出たばかりの時点でフォーマッタを標準ツールとして固定したことは、当時としては大胆な選択でした。多くの言語は数年かけて複数のスタイルガイドが乱立した後にようやくフォーマッタを作ったからです。

Go チームが早くからフォーマッタを標準化した理由は明確でした。スタイルの分断が起きる前に固定しなければならない、ということです。いったん複数のスタイルがコードベースに根づくと、その後で標準を導入することは政治的にほぼ不可能になります。皆が自分のスタイルに慣れた後だからです。Go はその混乱が始まる前に唯一の答えを提示することで、この問題を根本から封じました。

Rob Pike や Russ Cox をはじめとする Go 設計者の考え方は、いわゆる「Go の格言(Go Proverbs)」によく表れています。これらの格言は、Go が追求する単純さと明瞭さの価値を凝縮した文章です。

"Gofmt's style is no one's favorite, yet gofmt is everyone's favorite."
"A little copying is better than a little dependency."
"Clear is better than clever."
"The bigger the interface, the weaker the abstraction."

これらの格言を貫く精神は一貫しています。賢さより明瞭さを、抽象化の誇示より単純さを選ぶ、ということです。gofmt はまさにこの精神をコードの表面に適用した成果物です。「どのスタイルがより賢いか」を問う代わりに、「全員が同じ形を見る」という明瞭さを選んだのです。

興味深いことに、gofmt は単なるフォーマッタを超えて Go のツール文化全体に影響を与えました。gofmt がコードの AST(抽象構文木)を扱う方法は、その後 gorename や gopls といったツールがコードを安全に変形する基盤になりました。つまり gofmt は「コードをテキストではなく構造として扱う」という Go ツールエコシステムの出発点でもありました。

gofmt — 標準になったフォーマッタ

gofmt は Go 標準のツールチェーンに最初から含まれています。別途インストールも設定ファイルも不要です。この「設定なし」という特徴は意図された設計です。設定が可能なら、人々は設定をめぐってまた論争するからです。

# 一つのファイルをフォーマット
gofmt -w main.go

# パッケージ全体をフォーマット
go fmt ./...

# 変更点だけをプレビュー(書かずに diff を出力)
gofmt -d main.go

gofmt が扱うのは主に次のものです。

インデントをタブに統一
演算子の周囲とコンマの後の空白の正規化
インポートブロックの整列とグループ化
構造体フィールドや整列可能なコードの整列
不要な括弧の除去

ここで一つ明確にしておくべき点があります。gofmt はわざと「最小限」だけ手を入れます。動作に影響を与えずとも人によって意見が分かれうる領域の一部は、依然として手をつけずに残します。まさにその隙間に入り込んだのが gofumpt です。

gofumpt — gofmt よりもう一歩

gofumpt は「gofmt は正しいが十分に厳格ではない」という問題意識から出発しました。名前からして gofmt に対する一種の言葉遊びで、gofmt の出力はすべてそのまま有効でありつつ追加ルールをさらに適用します。つまり gofumpt を通したコードは gofmt も常に通ります(上位互換)。

gofumpt が追加で強制するルールの例をいくつか見てみましょう。

// gofmt は許すが gofumpt は整理するケース

// (1) 関数本体の開始と終わりの不要な空行を除去
func before() {

	doSomething()

}

func after() {
	doSomething()
}

// (2) 短い変数宣言のグループ化を推奨
// (3) 不要に長い空行を縮小
// (4) 一部の複合リテラルの一貫した形を強制

gofumpt の魅力は「追加設定なしでより整っている」ことにあります。gofmt の無設定の哲学をそのまま継承しつつ、人々がよく同意する追加の整理を自動でやってくれます。多くのチームが gofmt の代わりに gofumpt をデフォルトに採用する理由です。

ただし gofumpt が公式標準ではない点は覚えておくべきです。gofmt は Go チームが保証する単一の標準ですが、gofumpt はそれよりもう一段意見を重ねたサードパーティのツールです。この微妙な違いが、次に見る政治学の出発点です。

gofumpt のルールをさらに深く見る

ここまでは gofumpt のルールを大枠でしか見てきませんでした。今度はもう少し具体的なルールをコードで見ていきましょう。こうした細かなルールが積み重なって、「追加設定なしでより整っている」という gofumpt の印象を作ります。

第一に、8 進数リテラルの表記を現代的な形に統一します。Go 1.13 から導入された 0o 接頭辞を推奨します。

// gofmt は両方を許すが、gofumpt は 0o 形式を推奨する
perm := 0755   // 古い8進数表記
perm := 0o755  // gofumpt が好む明示的な表記

第二に、関数シグネチャで同じ型の連続したパラメータをグループ化するよう促します。

// 冗長な形
func move(x int, y int, z int) {}

// gofumpt が推奨するグループ化された形
func move(x, y, z int) {}

第三に、import グループの整列をより厳格に扱います。gofmt も import を整列しますが、gofumpt は標準ライブラリとサードパーティパッケージの間に散らばる意味のない空グループを整理します。

// gofumpt は不要に分割された import グループを整える
import (
	"fmt"
	"strings"

	"github.com/foo/bar"
)

第四に、空行に対するルールがより細かくなっています。ブロックの開始と終わりに付いた空行、連続した二つ以上の空行などを整理します。

// gofumpt が整理する空行のパターン
type Config struct {
	Name string

	Port int
}

// 上のようにフィールドの間に意味なく入った単一の空行も
// 文脈によっては整理の対象になる

こうしたルールは一つ一つ見れば些細です。しかしコードベース全体に一貫して適用されると、誰が書いたか分からないほど均質なコードができあがります。まさにこの均質さこそ、意見のあるツールが狙う効果です。

goimports — フォーマットと import 管理の結合

gofmt 系統を語るとき欠かせないツールが goimports です。goimports は gofmt が行うすべてのフォーマットをそのまま実行しつつ、さらに import 文を自動で管理します。使われていない import を除去し、コードで使われているが import されていないパッケージを自動で見つけて追加します。

# インストール
go install golang.org/x/tools/cmd/goimports@latest

# gofmt のように使いつつ import まで整理する
goimports -w main.go

# ローカルパッケージグループを別に分離するオプション
goimports -local github.com/myorg -w ./...

-local オプションは特に便利です。標準ライブラリ、サードパーティ、そして自組織の内部パッケージをそれぞれ別グループに整列してくれるので、import ブロックを見るだけで依存関係の出所が一目で分かります。

多くの開発者が日常で gofmt の代わりに goimports をデフォルトのフォーマッタとして使います。どのみち import 整理は常に必要な作業であり、goimports はそれをフォーマットと一度に処理するからです。gofumpt も goimports と組み合わせて使えるため、「gofumpt 水準の厳格さ + 自動 import 管理」という組み合わせが実務で人気です。

エディタ統合 — 保存すれば自動で整う体験

フォーマッタの価値を日常で最も強く実感する瞬間は、「保存時の自動フォーマット(format on save)」が有効なときです。開発者が意識しなくても、ファイルを保存した瞬間にコードが標準の形に整います。こうするとフォーマットはもはや「覚えて実行する作業」ではなく「ただ起こること」になります。

Go 陣営では gopls(Go 公式の言語サーバ)がこの体験の中心にあります。gopls はエディタと連携し、コード補完や定義へのジャンプといった機能だけでなく、保存時のフォーマットと import 整理まで担当します。ほとんどのエディタで、gopls を通じて gofmt または gofumpt を保存トリガーに結びつけられます。

// VS Code の settings.json の例 — 保存時に gofumpt でフォーマット
{
	"editor.formatOnSave": true,
	"gopls": {
		"formatting.gofumpt": true
	}
}

ここで重要な点は、チーム全員が同じエディタ設定を共有してこそ効果が最大化されるということです。誰かが保存時フォーマットをオンにし、誰かがオフにすると、コミットごとにフォーマットがばらついて diff が汚くなります。だから多くのチームはエディタ設定そのものをリポジトリに一緒にコミットするか、後で見る EditorConfig のようなツールで最小限の共通ルールを共有します。

他言語との比較 — prettier、black、rustfmt

Go が gofmt で作ったモデルは他言語のエコシステムにも大きな影響を与えました。いくつかを比較してみましょう。

ツール	言語	設定の可能性	哲学
gofmt	Go	ほぼなし	標準を強制、論争を終結
gofumpt	Go	なし(より厳格)	gofmt + 追加の整理
prettier	JS/TS など	一部可能	意見はあるが多少の余地
black	Python	ほぼなし	「妥協なきフォーマッタ」
rustfmt	Rust	かなり可能	標準を推奨、設定を許可

ここで興味深いスペクトルが見えます。一方の端には設定をほとんど許さない gofmt と black があり、もう一方の端には相当の設定を許す rustfmt があります。prettier はその中間のどこかに位置します。

Python の black は自らを「The Uncompromising Code Formatter」と呼びます。名前からして意見のあるツールの態度がそのまま表れています。black も設定の可能性を最小化することで「行の長さを何文字にするか」のような論争を封じます。

一方 prettier は一部のオプション(引用符の種類、セミコロンの有無など)を残して多少の余地を与えます。これは JavaScript エコシステムの多様性を反映した現実的な妥協ですが、同時に「そのオプションをめぐってまた論争が起きる」という副作用も生みます。設定を許した瞬間、その設定自体が新しい論争の種になるのです。

設定可能性のスペクトル — dprint、Biome、clang-format、EditorConfig

先の表は代表的なツールをいくつか扱っただけです。視野を広げると、フォーマッタは「どれだけ設定を許すか」という軸の上に一本の長いスペクトルを成します。両極端を理解すれば、自分のチームがどこに立つべきか判断しやすくなります。

一方の端には設定をほとんど許さない gofmt、gofumpt、black があります。これらは「選択肢をなくすこと」自体が目的です。反対の端にはほぼすべてを設定できるツールがあります。その中間にさまざまな折衷案が位置します。

dprint: Rust で書かれた高速なマルチ言語フォーマッタで、プラグイン構造によって複数の言語を一つのツールで扱います。prettier より設定可能性を意識的に広く開けています。
Biome: JavaScript/TypeScript エコシステムで prettier と ESLint を一つにまとめようとする試みです。フォーマットとリントを単一のツールに統合し、速さを強みに掲げます。
clang-format: C/C++ 陣営の代表的なフォーマッタで、設定可能性の極端に近いものです。インデント、波括弧の位置、整列方式など数十のオプションを細かく調整でき、LLVM・Google・Mozilla といった事前定義スタイルも提供します。柔軟ですが、まさにその柔軟さゆえに「自分のチームの clang-format 設定」をめぐって論争が起きがちです。
EditorConfig: 厳密にはフォーマッタではなく、エディタ間で最小限の共通ルール(インデントの種類、行末文字、ファイル末尾の改行など)を共有するための設定標準です。言語とエディタを問わず動作するため、本格的なフォーマッタを導入する前段階の「最小限の合意」として広く使われます。

# .editorconfig の例 — エディタ間の最小共通ルール
root = true

[*]
indent_style = tab
end_of_line = lf
insert_final_newline = true
charset = utf-8

このスペクトルが与える教訓は明確です。設定可能性が高いほどツールはより多くの状況に適応しますが、その分「設定をどうするか」という新しい論争を抱え込みます。逆に設定可能性が低いほど適応力は落ちますが論争は消えます。Go が意図的に後者を選んだという事実は、ツール設計がすなわち価値判断であることを示しています。

リントとフォーマットは違う

ここでよく混同される概念を整理しておきましょう。フォーマット(format)とリント(lint)は目的が異なります。

フォーマット: コードの「形」を扱います。インデント、空白、改行など動作に影響しない表面的な形です。
リント: コードの「内容」に対する潜在的な問題を指摘します。使われない変数、疑わしい比較、起こりうるバグのパターンなどです。

# フォーマット - 形を自動で直す
gofumpt -w ./...

# リント - 問題を指摘(golangci-lint の例)
golangci-lint run ./...

この二つを混同するとツール選びがこじれます。フォーマッタは「こう見えないコードは自動で直す」という立場で、リンタは「これは問題かもしれないので人が判断せよ」という立場です。良いチームは両方使いつつ役割を明確に分けます。フォーマットは機械に完全に任せ、リントは警告として人が検討します。

フォーマッタが手をつけないもの — 限界と例外

意見のあるツールだからといってすべてを決めてくれるわけではありません。gofmt がわざと手をつけない領域があることは先に触れましたが、その代表が行の長さです。prettier や black は「一行最大何文字」というルールで長い行を自動で折りますが、gofmt は行の長さについて何のルールも強制しません。行をどこで切るかは人の判断に委ねるのです。

これは意図された設計です。行を切る位置はしばしばコードの意味構造と結びついているため、機械が一律に切るとかえって可読性を損なうことがあるからです。たとえば次のようなコードでは、どこで改行するかは作者が意味を見て決めるほうがよいでしょう。

// 人が意味を見て行を分けた形
result := computeScore(
	player,
	difficulty,
	bonusMultiplier,
)

もう一つ、フォーマッタの決定をあえて逆らいたいときがあります。表形式に整列したデータや ASCII アートのコメントのように、自動整列がかえって壊してしまう場合です。多くのフォーマッタはこのための「ここは触るな」という指示子を提供します。

// gofmt は隣接する行のコメントを整列するが、
// 次のように意図的に整列を保ちたいときがある
var weekdays = []string{
	"Mon", // 月曜日
	"Tue", // 火曜日
	"Wed", // 水曜日
}

興味深いのは gofmt の哲学の一貫性です。prettier は // prettier-ignore のような明示的な脱出口を提供しますが、gofmt はそうした一般的な「フォーマット無視」の指示子を置きません。脱出口を開いた瞬間「どこまで無視するか」という新しい論争が生まれるからです。代わりに gofmt は、整列を崩したければ空行を一つ入れるといった、コード構造そのもので表現する方法だけを残します。この小さな違いにも「選択肢を最小化する」という哲学が一貫して表れています。

結局、フォーマッタの限界を理解することはフォーマッタをうまく使うことの一部です。フォーマッタは万能ではなく、意味が介在する領域は依然として人の役目として残ります。良いツールは自分が何をしないかを明確にすることで、人がどこに集中すべきかを教えてくれます。

チームの合意と CI 強制 — ツールをルールにする

意見のあるツールの本当の価値は CI で強制されるときに表れます。どんなに良いフォーマッタでも誰かが使わなければコードベースの一貫性は崩れます。だから多くのチームはフォーマットを CI 検査として固定します。

# CI でフォーマット違反を検査する典型的なパターン
# (変更が必要なファイルがあれば一覧を出力して失敗させる)
gofumpt -l . | tee /tmp/fmt.txt
test ! -s /tmp/fmt.txt

実際の CI パイプラインでは、この検査をワークフローの一ステップとして組み込みます。たとえば GitHub Actions では次のような形になります。

name: lint
on: [push, pull_request]
jobs:
  format:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-go@v5
        with:
          go-version: stable
      - name: Install gofumpt
        run: go install mvdan.cc/gofumpt@latest
      - name: Check formatting
        run: test -z "$(gofumpt -l .)"

最後のステップが核心です。gofumpt -l . はフォーマットが崩れたファイルの一覧を出力し、出力が空でなければ検査が失敗します。つまり「フォーマットされていないファイルが一つでもあればマージを止める」というルールがコードに刻まれるのです。

この小さな検査ひとつがコードレビューの風景を変えます。もうレビューで「ここに空白が一つ抜けています」のような指摘をやり取りする必要はありません。そういうものは機械が勝手にふるい落とすからです。レビュアーは本当に重要なこと、つまり設計とロジックに集中できます。

2026 年にはここに一つの流れが加わりました。AI コーディングエージェントが普及するにつれ、エージェントが生成したコードをフォーマッタとリンタで自動整理するパイプラインが標準になりました。AI が作ったコードでも gofumpt を通せば人が書いたコードと区別がつきません。意見のあるツールはこうして人間と機械の成果物を同じ形へ収束させる平準化装置としても機能します。

意見のあるツールの長所と短所

ここで意見のあるツールの光と影を整理してみましょう。

長所

論争の終結: スタイルに注いでいたエネルギーを実際の問題に使えます。
一貫性: コードベース全体が同じ形なので読みやすいです。
オンボーディングの簡素化: 新メンバーがスタイルガイドを覚える必要がありません。ツールが合わせてくれます。
レビューの集中: 表面的な指摘が消え、本質に集中できます。

短所と批判

柔軟性の喪失: 特定の状況でより読みやすい形があっても、ツールが強制する形に従わねばなりません。
標準の権威の問題: gofumpt のような非公式ツールを採用すると、「なぜ公式の gofmt ではなくこれを使うのか」という別の論争が生まれることがあります。
意見の注入: ツールを作った人の好みが全員に強制されます。これが「コードスタイルの政治学」と呼ばれる理由です。誰かの意見がツールという形で権力を持つのです。

ここで重要な洞察が一つあります。意見のあるツールが良い理由は、その意見が「正しいから」ではなく、意見が「一つに固定されているから」です。つまりツールの価値は内容の正当性ではなく決定の終結性にあります。この点を理解すれば、フォーマッタをめぐって「このルールが正しいか否か」を争うことがいかに本質を外しているかが分かります。

実戦事例 — 大規模コードベースに初めてフォーマッタを導入する

理論はきれいですが現実は違います。何年もフォーマッタなしで育ってきた巨大なコードベースに、ある日 gofumpt を導入することにしたとしましょう。最大の悩みは「これまで積み上がった数十万行をどうやって一度に整理するか」です。

最も単純な方法は、全体を一度にフォーマットして一つの巨大なコミットにすることです。

# リポジトリ全体を一度にフォーマットする巨大なコミット
gofumpt -w ./...
git add -A
git commit -m "style: apply gofumpt across the entire codebase"

この方法はきれいに見えますが、一つ深刻な副作用があります。すなわち git blame の汚染です。この巨大なフォーマットコミットがほぼすべてのファイルのほぼすべての行に触れるため、その後 git blame を回すと、数多くの行の「最後の変更者」が実際の作者ではなくこのフォーマットコミットとして表示されます。誰がなぜこのコードを書いたのかを追跡することが非常に難しくなるのです。

幸い Git にはこの問題のための解決策があります。特定のコミットを blame の計算から無視するよう指定する機能です。リポジトリのルートに .git-blame-ignore-revs ファイルを作り、無視するフォーマットコミットのハッシュを書いておきます。

# フォーマットコミットのハッシュを無視リストに追加
echo "a1b2c3d4e5f6 # style: apply gofumpt across the entire codebase" >> .git-blame-ignore-revs

# Git がこのファイルを常に参照するよう設定
git config blame.ignoreRevsFile .git-blame-ignore-revs

こう設定すると git blame はフォーマットコミットを飛ばし、その前の実際の作者を表示します。GitHub や GitLab といったホスティングサービスもこのファイルを自動で認識し、ウェブ UI の blame 画面に反映します。つまり「巨大なフォーマットコミット」の最大の欠点が消えるのです。

マイグレーション戦略を整理すると次のようになります。

一度に、別コミットで: フォーマット変更はロジック変更と絶対に混ぜません。純粋にフォーマットだけを変える単一のコミットを作ります。
無視リストに登録: そのコミットハッシュを .git-blame-ignore-revs に追加し、blame の汚染を防ぎます。
進行中のブランチを整理: 巨大なフォーマットコミットは進行中のすべてのブランチに衝突を起こします。あらかじめチームに告知し、可能なら作業の少ない時点を選んで実施します。
すぐに CI 強制を開始: 一度整理した直後から CI 検査をオンにして、再び散らからないようにします。

この事例が示すのは、フォーマッタ導入が単なるコマンド一行ではなく、チームの協業の流れとツールを併せて考えなければならない小さなプロジェクトだという点です。ツールの哲学がどれほど優雅でも、導入の現実はこのようにディテールに左右されます。

実務適用ガイド

最後に、実務で意見のあるツールを導入するときの推奨を整理します。

一つを決めて最後まで貫く: gofmt でも gofumpt でも、チームで一つ決めたらもう論争しません。ツールの目的そのものが論争の終結であることを思い出してください。
CI で強制する: 人の自律に任せれば一貫性は必ず崩れます。検査を自動化しましょう。
エディタの保存時フォーマットを設定する: 開発者が意識しなくても常にフォーマットされたコードを書くようになります。
リントと分離する: フォーマットは自動修正、リントは人の検討と役割を分けます。
AI 生成コードも同じパイプラインを通す: 出所が何であれコードベースの形は一つであるべきです。

おわりに

コードフォーマットツールの歴史は、些細に見える問題をいかに優雅に終結させるかという物語です。Go は gofmt で「選択肢をなくして論争を終わらせる」という強力なモデルを提示し、gofumpt はその上にもう一歩進みました。black、prettier、rustfmt はそれぞれのやり方でこの哲学を変奏しました。

意見のあるツールが私たちに教えてくれるのは、すべての決定が議論を経るべきではないという事実です。ある決定はただ誰かが下してくれればよいのです。その決定が完璧でなくても、全員が従うという事実自体が完璧さよりも大きな価値を生み出します。コードスタイルという小さな領域から始まったこの洞察は、AI がコードを大量に生成する時代にむしろより重要になっています。

もう少し遠くから見ると、gofmt が投げかける問いはコードスタイルをはるかに超えています。「どこまでを合意で決め、どこからをツールに任せるか」は、実はあらゆる協業の根本的な問いです。意見のあるツールはこの問いに対して一つの明確な答えを出します。正解のない領域では、決定を下す行為そのものが決定の内容よりも重要だ、ということです。私たちが毎日向き合う数多くの些細な選択 — ファイル構造、命名規則、コミットメッセージの形式 — の多くが、この教訓の適用対象です。gofmt はその小さな領域で先に答えを見せただけで、その精神ははるかに広いところまで届いています。良いツールは私たちを自由にはしません。むしろ些細な自由を奪う代わりに、より大きな自由を返してくれます。何を悩まなくてよいかを決めてくれること、それが意見のあるツールがくれる最も貴重な贈り物です。