命名の大切さ
名前は大切です。それは人の名前だったり、商品名だったり、そしてプログラミングにおける識別子だったり、どれも大切です。名は体を表す。設計と命名は表裏一体であり、良い命名は良い設計に繋がります。
ここでは主にGoの命名について考えていきます。
Goはよく名前を短くするの習慣であると勘違いされます。Goに入ってはGoに従えにおいても『与えられたコンテキストの中でわかりやすい名前にする』とされています。
命名についてはGoの命名規則という記事をみるとよくまとまっています。この記事で参照されている公式ブログの記事はかなり前の記事です。つまり、Goはリリース当初から名前が短ければ短いほどよいとしているわけではありません。
文脈を構築する
名前（識別子）は、プログラミング言語に登場するオブジェクトを識別するために用いられます。ここでは、変数、関数、定数、パッケージなどの命名できるものを指しています。
人の名前をフルネームで呼ぶことはあまりないでしょう。上田さんという名前で呼んでも、その呼んだ文脈によって同僚の上田さんか、ご近所の上田さんか区別が付きます。
プログラミングにおいても名前を呼ぶ場合は、その文脈とともに考える必要があります。net/httpパッケージの*Client型のメソッドがDoであれば、それはHTTPリクエストを送ることは想像しやすいでしょう。引数の型が*http.Request型であればなおさらです。SendHTTPRequestやSendRequestしても情報量は増えないでしょう。
名前が長くなってしまうと感じる場合は、うまく文脈が構築できていない可能性があります。文脈がないと、名前が説明的にならざる得ないでしょう。北海道苫小牧市に住んでいる、宮崎県出身の上田拓也さんのように呼ばないといけません。1度なら我慢できますが、何度もそんなに長い名前で呼ぶのは疲れます。名前が長いとソースコードも長くなり、重要な情報が隠れてしまい、可読性が下がります。
文脈は、パッケージ、関数、型、メソッドなどで構築できます。Goは他パッケージの機能を使うには、必ずパッケージ名を伴う必要があるため、パッケージ名も含めて命名を考えると良いでしょう。
テストで確認する
命名は誰のために行うべきでしょうか？定義をするパッケージのためではなく、利用するパッケージにおいての可読性を考えるべきでしょう。
自パッケージ内で可読性が高いように思えても、実際に利用し、命名が重要になるのは他パッケージにおいてです。テストコードのパッケージをmypkg_testのように、テスト対象のパッケージと別のパッケージにすることで、命名がうまく言ってるか確認できます。
命名がうまくいってない場合は、テストコードでも分かりづらいし、名前が長くなります。名前が長いとテーブル駆動テストのテストケースが縦に長くなり、改行を含む表計算ソフトのセルのように可読性が下がります。改行することで可読性をあげようとするのではなく、命名を工夫したり、リファクタリングすることで解決すると良いでしょう。
スケールを意識する
プログラミングは命名の繰り返しです。冗長な名前をつけていると、徐々に可読性が下がってきます。ソースコードの大半が長い識別子によって専有されるようになります。長い名前をいくら読んでも、情報量は増えません。
命名はスケールを考えておくと良いでしょう。たとえば、メソッドは増える可能性があり、引数の型をメソッド名に含めていると、引数のバリエーションが増えると名前はどんどん長くなり可読性は下がります。
フィールドやメソッドは増えていくことを忘れてはいけません。命名だけに限りませんが、何が増えるのかを予め予測し、備えておくと良い設計につながるでしょう。
ただし、1回の命名で素晴らしい名前がつけれ、それが未来永劫、素晴らしい名前とは限りません。文脈は変化していくので、リファクタリングを伴いながら良い名前を探っていく必要があるでしょう。
指針を得る
Google Style GuidesにGo Styleがあります。
このガイドラインは、Style Guide、Style Decisions、Best Practicesから構成されています。
Style Guideは、Goのスタイルガイドの基礎となる指針のようなものが書かれています。Style Decisionsには、より具体的な例が、そしてBest Practicesにはマストではないが、準拠すると良さそうなベストプラクティスが書かれています。
命名についても書かれているので、一度読んでみると良いでしょう。
宣伝
Gopher塾の#2 Goらしいコードの書き方では、命名などのGoらしいコードの書き方について扱う予定です。学生は無料ですので、ぜひご参加ください。