見えないルール

本格的なソフトウェア開発企業で働くとき、最初の頃にまずコーディング規則や慣習などのガイドラインに目を通したかと思う。基本的なガイドラインとして、 gotoは原則使用禁止だとか、インデントにはスペースではなくタブを使用すべきであるとか、またはその逆などがあっただろう。ひょっとしたら continue禁止や、複数リターン値禁止など、ちょっと変わってるように思える慣習や、あまり直感的とは言えないルールといったものもあったかもしれない。
可読性を高めたり、メンテ性を向上させるには、どんな規約が有効だっただろうか？ドキュメント上では一見良さそうに見えたが、実際はイマイチだったものなどあるだろうか？
いいコーディング規約、悪いコーディング規約？ | スラッシュドット・ジャパンデベロッパー

職業プログラマならば誰もが目にするであろうコーディング規約。コードの書き方に一定のルールを設けることである種のバグを予防し、可読性と保守性を向上させるのが主な目的。とはいえ、プログラマは独自のポリシーを持つ人も多く、窮屈に感じる人も多いでしょう。中でも特にうるさいyasuhoが長々と持論を展開しますよ。：）

yasuhoの考えるコーディング規約

意図するところを明記するべし

私の見たコーディング規約は守るべきルールはあっても、その意図するところの説明はなかった。個人的にはルールブックとは別にその意図の解説本があるべきだと思う。例えそれが自明であったとしても、全ての人がそれを理解しているとは限らない。

例えばよくあるgoto禁止事項。私は使い方によってはgotoは有用だと思うし、実際使っている。大事なことはgotoの何が危険で、何が有用かを理解することであって、ルールを守ることが目的ではないはず。

定期的にアップデートすべし

規約は定期的に見直しを行い、改変していくべきと考える。

近年プログラミングとそれを取り巻く環境はどんどん変化している。言語が変わらなくても、新たな概念を導入する必要はあるはずだ。単に昔からの慣習で残されているルールなどは淘汰されるべきだろう。

冗長なルールにしない

ルールはシンプルでプログラミングの妨げとなるものは避ける。

関数やメソッドの先頭に書かれるインタフェースのコメントは誰もが見たことがあるだろう。だが、実際のインタフェースとは違っているケースも誰もが経験あることと思う。結局はみな面倒だし、気が付かないことが大半だからだ。機能しないものならば、思い切って簡略化することも一つの方法。

コメントの書き方

コメントの書き方も規約に書いてよいのではないかと思う。

ここで言うコメントは前述のインタフェースのようなものではなく、もっと一般的な、たとえば、分かりにくいアルゴリズムの補足や処理を分かりやすくするために書かれるもの。ルールというより、コメントはどのような時にどう書くか、といった指針のようなものがあるとコードの見通しがだいぶ違ってくるはずだ。

ちなみに個人的にはコメントは極力少なく、が目標。よいコードはコメントがなくともシンプルで分かりやすいものだとyasuhoは考えるから。

個人的には、これら一般的なコーディング規約以上に大切な「ルール」があると思う。それはソフトウェアの実装ポリシーの統一という「見えないルール」。

よく出来たソフトウェアは、振る舞いが容易に想像できる一貫した処理形態を持っている。自分の望む機能が直感的に分かる。それを行った後の結果が想像しやすい。そういうプログラムは使っていて安心できるし、信頼もされるものだ。

そのためには、ソフトウェアの各コンポーネントの動きが統一されていなければならない。プログラミングにおいては仕様は一つでも実装方法は多くのやり方がある。厳密な仕様でさえいろいろな解釈が可能なのだから、実装はまさにプログラマの思想が色濃く反映されたものになる。

その実装を統一するには設計段階からソフトウェアのポリシーを定めておくことが重要だと思う。処理速度・応答速度・メモリコスト・拡張性、などといった相反する目標を、どんな時どのように優先させるのか。エラー発生時の後処理はどうするか。各クラスやコンポーネントにどんなインタフェースを用意し、どのように関連づけるのか。そういった「実装依存」な処理の統一がキーではないだろうか。

そしてそれを達成するのはドキュメントではなくポリシーを反映したコードを最初に作ることなのだと思う。ソフトウェア開発では既存のコードを参考に機能を追加したり改善するといったケースが圧倒的に多い。参考にするコードがよくできたものならソフトウェアの品質は良くなるし、逆なら悪くなる。それはどんな優れた規約やドキュメントよりも効果があるとyasuhoは信じているし、そう信じたい。