見やすいコードのためには見た目にも気をつかえ

コーディング標準というのはコードを書くときの「プログラムには直接関係しない」部分の書き方の取り決めのことです。具体的には名前の付け方、インデントの使い方なんかがそれに当たるわけですが、良いプロジェクトというのはそういうものの統一がうまく図られているものです。 そのため、良いプロジェクトならば、たとえば関数名を見ただけで中身を読まずともある程度その動きが予想できるものです。逆にいえば、そういうものを意識して書かないと本当に良いコードにはならないということです。 この類にはある程度ドキュメント化されている部分もありますが、慣例的な部分も多々ありますので、実際にこの暗黙の取り決めを覚えるにはたくさんのコードを読む必要があります。その点、この本のように、本当に基本部分ですがある程度まとめてくれているというのは結構助かります。

ドキュメントはソースとは違う

今度はドキュメントの読み方です。ドキュメントといっても仕様書のようなものからmanの内容・コメントなど広範囲の内容になります。 ドキュメントを読むときに一番気をつけなくてはならないのは、それが「プログラムではない」ことです。プログラムは"書いたとおりにしか動かない"のですが、逆にドキュメントは"書いてある通りに動くとは限らない"というところが大きな違いになります。もちろんプログラムとドキュメントが同じになるように努めているはずではありますが、そういう可能性もあるということを意識しておくことが大事。 ただ、そのドキュメントが書かれたからには何らかの理由はあるわけで、そのドキュメントを読むことは内部を調べる上で非常に役に立つはずです。

プログラムを動かすためには必要ないが・・・

今回の範囲は「守らなくてもプログラムは動く」部分です。しかし、だからこそコードを読みやすくするためには重要な部分ですし、コードを読み解いていく上でも意識しなければならないという感じです。

次回

次はアーキテクチャの部分と全体を合わせた総合的な内容の予定です。ちょっと見た感じ今までのとこより難しそう・・・。とりあえず次回で終了（予定）です。