Goのコードを読んでいると変数名がやたらと短いことにすぐ気がつくと思う。c, i, nみたいな1文字変数や、br, wr, errみたいな2〜3文字の変数がいたるところで使われている。これは他の言語、特にJavaみたいな言語と比べるとぱっと見でずいぶん違うところだ。
どうしてこんなに短い変数名でよしとしているの？ という疑問を抱くのはもっともなことだ。でもそれに対しては、なぜそんなに変数名が長くなくてはいけないの？ という質問を返すことになると思う。
Goは、最近では当然のものとして受け止められている（が昔は特にそうでもなかった）「プログラミングの常識」を改めて問い直した言語だ。
たとえば、複雑なクラス階層のあるオブジェクト指向言語機能は、本当にプログラミングを簡単にするのに役立っているのだろうか？ 例外機構はそれが持ち込むややこしさに見合う存在意義があるのだろうか？ ジェネリクスやテンプレートは、その複雑さ、コンパイル時間の増加、あるいはランタイムの実行性能の低下に見合うだけの価値はあるのだろうか？ 静的リンクに比べて複雑な動的リンクは、そのコストを正当化できるだけの価値がいまだにあるのだろうか？
Goが問い直してるのはそういう点だ。80年台とか90年台から今日まで、多くの人がそういう「モダンな」コードを書いて、そういうシステムを運用してきたわけだけど、その経験を踏まえてみると、昔はよいアイデアだと思ったものが今日でもそのまま肯定的に受け入れられるというわけではないと思う。
変数名も同じだ。長い変数名は、毎回それを使うときに長い名前を繰り返し書かなければいけないほど、その名前が重要なのだろうか？ ローカル変数numberOfBytesReadはnと比べて本当に読みやすいのだろうか？
Goをしばらく書いていると、cはチャネルに使われることが多いし、wはWriter、rはReader、といったようにパターンがわかってくる。また、1つのパッケージの中では普通名前付けが一貫しているので、短い名前でも混乱することはほとんどない。一方で短い名前はプログラムが明らかに見やすいという利点がある。
これは究極的には好みの問題に過ぎないが、一貫性を重視して、GoではGoの名前付け規則に従うのが良いと思う。
どういう名前付け規則がよいのかピンとこないひとは適当にGoの標準ライブラリを眺めてみると感覚がつかめるだろう。なんでもよいけどたとえばbufioあたりを薦めておく。