あるプログラマがいて、その人があるプログラムを目にしたとします。 そこでそのプログラマはそれを読解しようと試みます。 しかし彼は読解できませんでした。さて、その原因はなんでしょう。
プログラムを読解するためには、読み手とプログラムに、ある条件が必要です。
前者は単にプログラムの命令1つ1つについて理解できるか。英語でいうならば、 単語の1つ1つや基本文法を知っているかということです。 それに対して後者はプログラム全体がどういったことを表現しているのか。 英語でいうならば、その文章全体の意味することが理解できるかどうかということになります。
もう少しの間例え話をします。 前者についていえば、単に英単語や英語の熟語を覚えるといった勉強をすれば、クリアできます。 つまりプログラムでいえば、言語と必要な機能の仕様さえ知っていればいいことになります。 しかし後者は、英語だけの問題ではないかもしれません。 例えばそれがサスペンスの小説だったとしたら、 結局読み手は犯人の犯行動機が何であったのかが最後までわからずじまいになってしまったとしましょう。 その原因は、あまりに話のストーリーが複雑すぎてわからなくなってしまった場合(読み手の読解、理解力不足)、 ストーリーはさほど複雑ではかったけれど、文章の書き方が支離滅裂でとにかく読みにくくて理解できなかった場合 (書き手の文章力不足)によると思います。
さて、整理すると、書いてある表現が理解できないという 問題の責任は、2人の立場の人間に存在します。
さて、責任は書き手と読み手、両者にあるわけですから、両成敗してしまうのがいいですね。 読み手が文章を理解できるようにするには、 書き手が読みやすいきれいな文章を記述し、 読み手はある程度の文章は理解できる読解力を身につけるればよいということになります。
話をプログラムにもどします。 プログラムが読解できないといった状況をなくするためにはどうしたらいいのでしょうか。 答えは先ほどとまったく同じ、 書き手がなるべく読みやすく記述し、読み手はなるべく読解力を身に着ければいい のです。
ではプログラムにおいて、書き手にはどのような努力が必要なのかといった内容を、具体的にしていきましょう。
一般的な、書き手の幾つかの心がけを紹介します。
上記心がけについて、簡単なプログラムを交えて説明していきます。 ここではC言語で例を記述しますが、読むに際して、C言語がわからなくてもかまいません。 ただ読みやすそうか読みにくそうかがわかればそれで十分です。
変数名や関数名は、日本人以外が読むことも考えて、必ず英語で命名してください。 コンピュータ業界では英語がデファクトスタンダードだからです。 もしも英語で書かれていない場合、もし「kamuKim」と書かれていても、なんのことだかさっぱりわかりません。 (韓国語だとするとキムに感謝となる？)
インデントや改行を適切につけるのとそうでないのとでは、プログラムの可読性は、大きく変わってきます。
#include <stdio.h>
void yahoo() {
static int roopNum = 1;
int i;
for (i = 0 ; i < roopNum ; i++) {
fprintf("ヤッホー！");
}
roopNum++;
}
void main() {
yahoo();
}
#include <stdio.h>
void yahoo() {
static int roopNum = 1;
int i;
for (i = 0 ; i < roopNum ; i++) {
fprintf("ヤッホー！");
}
roopNum++;
}
void main() {
yahoo();
}
どうでしょうか。前者より後者のほうが、あきらかに見やすいですよね。 異なる点は、インデントと改行の有無なのですが、可読性のちがいは明白です。
小技とは、普段あまり使わない文法だけど、 ある部分についてはあえて使うことによって見栄えがよくなったり、簡潔に書けたりする、というような記法です。 例えば三項演算子などは、結構嫌うプログラマが多いですが、これを使いこなすと、可読性が高くなることもあります。
if (capable) {
fprintf("いいそうです");
} else {
fprintf("ダメだそうです");
}
fprintf((capable) ? "いいそうです" : "ダメだそうです");
デザイン・パターンとは、プログラムデザインなどのデザインです。 プログラムには、たいていの場合、その処理の流れは、共通する部分があり、 その共通する部分について、分かりやすい言い回し(記述方法)を定着させたものが、デザインです。 デザイン・パターンは、処理の流れを抽象化しやすいオブジェクト指向で多様されていて、 オブジェクト指向を勉強するといえば、デザイン・パターンを勉強するというようなものです。 オブジェクティブな開発において、デザインを使わずして、中・大規模プログラムは作成できないでしょう。
あいにくデザイン・パターンは、心がけ1つですぐに使いこなせるようになるようになるものではありません。 デザイン・パターンの専門書等を購入して、デザイン・パターンに関する勉強を行う必要があります。
かといって、実際のプログラミングでは、デザイン・パターンを使うと、初めて読む人にとってはプログラムの追跡が困難になります。
職場で使う時には、みんなに理解しやすい範囲内で適用できるものがあれば適用するという程度に留まらなければならないのが現実です。
さて、では、書き手がこれだけの努力をして記述したプログラムは、 必ずしも読み手に読解できるでしょうか。 答えは必ずしも読解できるとはいえないです。 なぜでしたか？理由は最初のほうで触れていましたね。読解力がない場合は読解できないんでしたね。 読解力がなければ読解力を付ければいいだけです。
プログラムの読解力の向上は、自分がプログラムを組むことでも可能ですが、 それ以上によい方法として、やはりプログラムを読むことで読解力が向上します。
読解力があれば、いろいろな人のプログラムを読むことができるようになって、 いろいろな人のプログラムを読むことで、読解力だけでなく、 自分のプログラミングのセンスも向上することに繋がります。
さて、可読性可読性と繰り返してきましたが、では、書き手以外が読むことがないプログラムは、 あまり可読性を気にする必要はないのでしょうか。 もうわかっている方も多いとは思いますが、おおいにあるんですね。
可読性を気にしないで、気の向くままにプログラムを書き進めていった結果出来上がったプログラムは、 その後、書いた本人でさえ、読解が困難です。 結果が1ずれているからここらへんで1足しておこうなどと思って当時付け足した処理が、 数ヶ月後に見てみると、「はて、なんでここにこんな処理があるんだろう。」となってしまうわけですね。
で、書き手も読めないプログラムというのは、 誰がどう見ても、どこをどういじったら処理がどう変わるのかといったことがわからないわけですから、 そのプログラムを変更するということが実質できないわけですね。 なかなか苦労してつくったプログラムを変更したくてもできない。 処理を変えることができないから、一から作り直すしかないわけです。 しかしそれはあまりに時間の無駄ですから、 プログラムを作成するときは、とにかく早く完成させたいという気持ちも芽生えるかもしれませんが、 その後のことを考えると、とにかく可読性だけはきっちりとしたプログラムを書くことのほうが重要です。
しかも、あまりにも可読性が低い場合、プログラムを組んでいる最中でも、 プログラムの見通しが悪いため、自分の書いたプログラムの処理を振り返って考えをまとめ直そうという場合などに、 読めないほどではなくても読みづらいものだから、そこでもよけいに時間をとってしまい、 結果的に完成が遅れるということもありえます。
というわけで、プログラムを記述する際には、 読み手だけではなく、自分のためにも、 読みやすいプログラムを記述することが大切だ 、ということが、わかって頂けたでしょうか。
では本項のまとめです。