可読性

十分な検討と整理の継続が情報処理の実務の根幹となる。可読性においてもまずこの点を注意すべきだ。

ソフトウェア言語は人間には理解しにくい機械語をわかりやすくするためのものだ。従って可読性は重要な要素になる。可読性をおろそかにする事が大きな問題となる事を理解する必要がある。

第一の問題はバグの発生だ。ソースが読めないためにバグが生まれるのは当然の結果だ。しかし読めないプログラムを書いて奇妙なバグを作りこむ技術者は多い。可読性が悪いとバグを取るのも難しい。目視でのチェックは昔から非常に重要だが、可読性が悪いとできない。目視チェックはデバッガが進歩する以前の主要なバグ取り手法で、机上デバッグと言って印刷した紙を机に載せてチェックしていた。現在でも目視チェックは重要で、可読性が悪いと品質が悪くなる。

第二の問題はプログラム構成の悪化だ。可読性と構成は直接的な関係を持つ。構成の悪さは作業効率の低さ、無駄なソースの発生、実行速度の低下など様々な悪影響をもたらす。理解しにくい物を作れば作業時間は増え、残業も増え、士気も下がるというのは当然の結果だ。時間が無くなって急いで作ろうとすれば、余計に可読性と構成を悪くする。こういう泥沼の作業で技術力は向上しない。

第三の問題はメンテナンスのしにくさだ。一応完成しても潜在バグ修正や機能追加がやりにくくなる。メンテナンスは他の作業者に渡る場合が多く、開発時より状況確認が困難になる。最終的に頭から作り直す状況も起こり得る。可読性の悪いプログラムが増えても資産の増加にはならない。

基本となるのは、同一のデータや処理を一つにまとめる事と、データと処理を一体的に扱う事である。また可読性は、整理と処理削減、品質向上、モジュール分割等と直接関係している。

同一表記

可読性を上げる際に最も重要なのは、同じものを同じ表記にする事だ。これは可読性だけでなく作業効率に大きな影響を持つ。

同一表記が重要なのは検索できるからだ。検索できる事は置換できる事でもある。これにより全体的な修正が容易になる。検索を使ったことのない開発者は存在しないと思うが、重要性を十分に理解している者は少ないと思う。検索と置換は徹底的に使わないといけない。

全体的な修正ができると、プログラム開発中に整合性が悪くなった際に大幅な改善が可能になる。例えばデータの配置に問題があると分かったら、一気に別の場所に移せる。この作業を行わずに品質の高いプログラムを作るのは難しい。特に規模の大きなプログラムでは重要である。

同一表記を保つには変数名やコメントだけでなくスペースの数にも気を配る必要がある。関数呼び出しの"("の次にスペースを入れる場合は常に入れて、入れない場合は常に入れないようにする。この差だけで関数呼び出し全体の検索ができなくなる。

プログラム構成

可読性とプログラム構成は直接的な関係を持つが、構成に踏み込むと可読性を大幅に超えてしまうため、可読性に近い話だけに限定する。モジュール分割も読んで欲しい。

プログラム構成は処理よりもデータを中心に考えるべきだ。処理とデータは強く関係しており、データの方が少ないので整理しやすい。

第一に構成の一貫性が重要だ。一貫性がないと理解は困難になる。Aに関するデータの一群に、Bに関するデータを混ぜてはならない。処理Aをしている最中に、処理Bを混ぜてはならない。

第二に同じデータや処理をまとめる事が重要だ。同じデータを多数コピーすると何が有効か分からなくなる。同じ処理はできるだけ一つの関数等にまとめるべきだ。似た種類のデータや処理も一カ所にまとめた方が分かり易い。表面的な意味でなく実体的な意味を理解してまとめる必要がある。

第三に抽象性のレベルをそろえるべきだ。これはある程度技術力が必要になる。関数呼び出しが増加し階層的になると、下の処理は具体的になり上の処理は抽象的になる。一連の処理において抽象性のレベルが合っていないと可読性が悪くなる。全体の指揮は指揮だけにして、具体的な計算は計算だけにすべきだ。ただし抽象化は実行速度低下やソース量増加など負の側面も持っているので注意しなければならない。

名前の付け方

最も重要なのは前述の同一表記だ。別の変数名でも同一の機能群に属する場合は同一の名前を入れた方がいい。名前が長くなっても検索が効く利点の方が大きい。

正しく機能を示している事も重要である。名前を見て機能がわかれば、文字通りソースを「読める」ようになる。プログラムの構成を正しく行うためにも有効である。名前が機能から外れたら修正しないといけない。同一表記を守り検索と置換が可能なら難しい作業ではない。

正しい英語を使う事にも注意して欲しい。意味や綴りが違う変数名を見ると気力が失せる。ソフト開発で英語と接するのは避けられないので、勉強という意味でも正しい英語で書くべきだ。

長い名前になると短縮する必要が出てくる。この場合にも可読性を保ちながら短縮しないといけない。子音のみを抽出したり、単語の頭文字のみを抽出すると、意味が解らなくなる可能性がある。単語の原型を保つようにした方がいい。

ただし歴史的に文字ごとの意味が決まっている場合がある。数値計算でベクトルや行列を扱うBLASがそれで、例えばzaxpyなら倍精度複素数のAx+y計算と言う事に決まっている。この場合は読み手が文字ごとに解読できるので可読性は高いと言える。

コメントと見た目

コメントは過剰に入れてもいいと思う。少なすぎて困った事はあるが、多すぎて困った事はない。ソースコードのように気を使って書く必要もないのでどんどん書いて欲しい。

可読性の高いソースならコメントなしでも理解できる。重要なのはソースに書かれていない事だ。作る上での根拠や、疑問点や、他のソースとの連動性はソースを読んでもわからない。開発資料がソースと共にあるという保証もなく、細かい部分まで資料に書くのは過剰である。ソースから少し離れたコメントを最も重視すべきだ。

純粋な見た目の美しさはあまり重要ではない。ソースの列がそろっているとか空白行の有無などだ。開始列は必ずそろえた方がいいが、他は違和感がなければ十分だろう。今までの経験だと、見た目が過剰に悪いソースは品質も悪いが、きれいなソースでも品質が悪い事もある。品質が良いソースならある程度の見た目が保たれている。品質に気を配るため自然と見た目が良くなる状況が最善だろう。見た目にこだわって書いても大して意味はない。