gofmtは、Go言語に同梱される公式のソースコード整形ツールである。2009年にGoが公開された当初からツールチェーンの一部として用意されており、Robert Griesemer氏、Rob Pike氏、Ken Thompson氏らGoogleの初期チームの設計思想を体現する存在として知られる。「インデント幅をスペースかタブか議論する時間があるなら、その分プログラムを書こう」という割り切りのもと、コードの整形ルールを一意に固定し、プロジェクトや個人の好みでスタイルが分かれる問題そのものを根絶した点が、後続言語の標準フォーマッタにも強い影響を残した。
この記事の目次
- Go設計思想と整形の役割
- ワークフローへの組み込み方
- 後続言語に与えた影響
- 派生ツールと拡張
- まとめ
Go設計思想と整形の役割
Go言語が登場した2009年当時、CやC++、Javaなどの主流言語では、コードの書式は各プロジェクトのスタイルガイドに委ねられ、波括弧の改行位置や関数間の空行の数、ポインタアスタリスクをどちらに寄せるかなど、無数の議論が繰り広げられていた。Robert Griesemer氏、Rob Pike氏、Ken Thompson氏らGoの設計チームは、こうした「決められたルールがないことが生む摩擦」を初期段階から問題視しており、「コードは1種類の書式しか存在しない」という設計判断とともに、その書式を機械的に強制するgofmtを言語と同時にリリースした。
gofmtの実装は単純な置換ではなく、Goのパーサで構文木（AST）を構築し、それを公式の整形規則に従って書き戻すという手順を踏む。そのためコメント以外の部分は完全に標準化され、空白や改行の使い方、インポート文の並び、構造体フィールドの整列など、開発者の主観が入り込む余地が一切ない。「タブを使う」「行末スペースを除去する」といった基本ルールから「複数の連続するimportはグループ化する」などの細部まで、すべて言語仕様の一部のように扱われている。
ワークフローへの組み込み方
gofmtの使い方は単純で、gofmt -w main.goとすればその場でファイルを整形し、gofmt -lとすれば未整形のファイル一覧を出力する。Goの公式VS Code拡張やJetBrainsのGoLandをはじめ、主要なエディタはファイル保存時に自動でgofmtを呼ぶよう設定されており、開発者は基本的に整形を意識する必要すらない。結果としてgit diffには空白の差し替えのような無意味な変更が混ざらず、レビュアーは本質的なロジック差分だけに集中できる。
CIパイプラインではgofmt -lあるいは派生ツールのgoimports -lを実行し、未整形のファイルが含まれていればビルドを失敗させる運用が定着している。Go 1.17以降ではgoimportsの機能の一部、特にimport文の自動整理も標準ツール側に統合されつつあり、gofmtの守備範囲がじわじわ広がっている。「整形は機械の仕事、判断はレビュアーの仕事」という分業を、ツールチェーンの側から強制してくれるのがGoエコシステムの心地よさだ。
後続言語に与えた影響
gofmtが切り開いた「議論のない単一公式フォーマッタ」という思想は、後続の言語設計に明確な影響を与えた。Rustのrustfmt、JavaScriptのPrettier、PythonのBlackなどは、いずれもgofmtを直接の参照モデルとして名前を挙げ、「設定可能項目を絞る」「論争を避ける」「標準として強制する」というスタンスを共有している。Prettierの作者James Long氏も初期記事の中でgofmtからの影響を語っており、JavaScript界に「整形を議論しない文化」を持ち込むきっかけとなった。
もちろん、ユーザー側からは「もう少し細かく設定したい」という要望も常に寄せられ続けてきたが、Goチームはほぼ一貫してそれを拒否してきた。Russ Cox氏が「すべての規約に同意するわけではないが、それでも全員が同じ規約に従っていることのメリットの方が大きい」と語った言葉は有名で、個人の好みを犠牲にしてでもエコシステム全体の一貫性を優先する、というGoの哲学を象徴している。結果として、ライブラリAとライブラリBで書き方が違うという混乱はGo界では起こりにくく、コードリーディングの認知負荷が下がる現実的な恩恵が生まれている。
派生ツールと拡張
gofmtの厳格な整形ルールに対して、コミュニティからはいくつかの派生ツールが生まれている。Mikkel Vestergaard氏らが開発するgofumptは「gofmtよりさらに一歩踏み込んだ整形」を提供し、空行の重複削除や%v系のフォーマット指定子の正規化など、より細部までスタイルを統一する。Daniel Martí氏のメンテナンス下にあるgolinesは「1行が長すぎる関数呼び出しを自動で折り返す」役割を担い、可読性向上のための補助ツールとして使われる。
もうひとつ重要なのがgoimportsで、これはBrad Fitzpatrick氏が中心となってGo初期に作られたツールで、未使用importを削除し、不足しているimportを推測して追加してくれる。現在ではgolang.org/x/tools配下で公式に保守されており、エディタ統合の標準として浸透している。gciはimportを「標準ライブラリ」「サードパーティ」「自プロジェクト」のグループに分けて並び替える機能を提供し、より細やかな統一を望むチームで重宝されている。いずれもgofmtの哲学を踏襲しつつ、現代的な要望を補う形で共存している。
まとめ
gofmtは、Go言語が初日から標準として整備した公式フォーマッタで、整形に関する議論そのものを過去のものにした存在である。rustfmtやPrettier、Blackなど、後続の言語フォーマッタが共通して参照する原点でもある。「コードはみな同じ形に整える」というシンプルな約束が、Goの読みやすさと開発スピードを下支えしている。
※本記事はIT用語辞典の手書きドラフトです。公開前に最新情報・出典を確認のうえ加筆修正してください。
コメント