コーディングスタイル

「プログラミングに関する雑多な事柄」がテーマの本連載，第2回の今回は「コーディングスタイル」について取り上げたいと思います。

コーディングスタイルは，コードの書き方に関するスタイルです。インデントのしかたや，変数名・関数名の表記法などはコーディングスタイルで扱われる要素の代表例です。

コーディングスタイルが異なると，同じ意味のプログラムでも見た目はだいぶ変わります（注1）。

for (i = 0; i < 10; i++) {
    printf("%d\n", i);
}

for (i = 0; i < 10; i++)
  {
    printf ("%d\n", i);
  }

注1）

Cのコードのスタイルはindentというツールで変換できます。

スタイルの一貫性

スタイルをごちゃまぜにするとコードが非常に読みづらくなるため，1つのプロジェクトの中ではコーディングスタイルの一貫性を守ることが重要です。

スタイルにも個人の趣味というものがありますが，個人の趣味よりもプロジェクト内での一貫性のほうが重要です。あるスタイルで書かれたコードを修正するときに，自分の趣味に合わないからといって，部分的に自分の趣味を取り入れても浮いてしまうだけです。

まれに，オープンソースのプロジェクトへのパッチで，元のプログラムと異なるコーディングスタイルを使っているものを見かけますが，これはあまり歓迎される方法ではありません。

スタイルの選択

プログラミング言語によっては，開発者のコミュニティ内でスタイルに関する合意がとれているものがあります。たとえば，Javaの場合はCode Conventions for the Java（注2）というSunのオフィシャルの文書があります（注3）。このような場合はそれに従うようにしましょう。

一方，CやC++ではさまざまなスタイルの慣習があり，厄介です。ゼロからプロジェクトを始めるなら，広く使われている慣習の中から自分の気に入っているもの，気に入ったものを選ぶとよいでしょう。まったく独自のスタイルを新たに編み出すのは得策とはいえません。いずれにしても，どのスタイルを使うかよりも，スタイルの一貫性のほうが重要です。

注2）

http://java.sun.com/docs/codeconv/

注3）

さらに，それをチェックするcheckstyleというツールがあります。
http://checkstyle.sourceforge.net

スタイルに関する議論

コーディングスタイルは開発者の間での議論を呼びやすいトピックです。というのも，スペースを入れるの入れないのといった事柄は誰でも口をはさむことができますし，厳密な優劣などつけられない問題ですから（だいたいは慣れの問題です），議論が紛糾することもめずらしくありません。

一方で，高度なアルゴリズムの詳細に関する議論などでは，口をはさめる人がいないため，議論はあっさり収束したりします。このような現象は「自転車置場の議論」としてFreeBSDのコミュニティで知られています（注4））。

複数のメンバで開発をする上では，コーディングスタイルをあらかじめ決めておくと無用な混乱を避ける役に立ちます。とはいえ，スタイルを決めておいたとしても，解釈にあいまい性が生じたり，想定外のケースが出てきたりすることはよくあります。

私の見る限り，生産性の高いプログラマはコードだけでなく，議論を早く片づけることも得意のようで，スタイルに関する瑣末（さまつ）なことをうだうだと議論しないで，さっさとけりをつけてしまいます。あるいは，はじめからそんな議論には参加しません。スタイルの一貫性を守ることは大切ですが，微妙なケースに関しては変にこだわり過ぎないことも大事です。

とはいうものの，瑣末なことをうだうだ議論するのは，食事どきなどの害のない時間にやる分には，案外楽しかったりします。filenameかfile_nameか，HTTPServerかHttpServerかなど，どっちがよいともつかないような事柄を議論していれば，あっという間に時間が過ぎるはずです。

ありがちなパターンは，昔の×× BASICでは変数名が短いほうが実行が速かったとか，昔は雑誌に載っているプログラムを入力してゲームで遊んでいたものだとか，いつのまにか全然関係のない昔話に脱線して，さらに無駄な議論が長引くというものです。その場にいる人の大半がついていけなくなるまで時代を遡（さかのぼ）るとようやく終わりを迎えます。

注4）

http://0xcc.net/blog/archives/000135.html

まとめ

今回はコーディングスタイルについて書きました。コーディングスタイルはプログラミングの生産性を高める1つの手段です。スタイルを守ってコードの読みやすさを保っていれば，プログラミングにおけるもっと難しい問題に集中できるはずです。