プログラマーの理想と現実

第9回 パターン認識とスタイル

2015.04.08

この記事は、『UNIX Magazine』2004年6月号(2004年5月18日発売)に掲載された同名記事の初稿(著者から編集部に提出したもの)を元に、Web掲載用に一部を修正したものです。10年以上前に執筆したものなので、現在のUNIXを取り巻く環境とは色々と異なることがありますが、プログラミングに対する心構えとしては現在でも通用するものと思い、再掲してみることにしました。

・・・・・・・・・・

バグを仕込んでしまった。懸命にその原因を探すが、なかなか見つからない。そこへ先輩技術者がやってくる。

先輩: どうしたんだい?

後輩: いや、バグを仕込んでしまいまして…

先輩: どれどれ?

先輩技術者は端末を覗き込む。そこには、エディタで開かれたソースコードが。

先輩: あ、これまずいなぁ。これじゃ動かないね。

先輩技術者は、簡単にバグの原因を見つけてしまう。あんなに探して見つからなかったのに。

……

良くある光景だ。先輩技術者には、これまで培ってきた経験と知識がある。その蓄積があるからこそ、バグの原因がすぐに見つけられる。傾向として、経験を積めば積むほど、バグの原因を見つけるまでの時間は短くなる。経験豊富なベテランともなると、コードを一見して即座にバグを指摘できる。とてもコードを読んでいるとは思えない早さで。

まるで手品か魔法のようだ。どうしてコードを読まずにバグの原因がわかるのか?それとも、ひと目見ただけで全部読んでしまうのだろうか?それはそれでやはり驚異だ。

斜め読み

もちろん、手品や魔法でコードを書くわけじゃないんだから、タネも仕掛けもなければ魔力も関係ない。感覚的なもので説明しにくいのだが、多分なんらかのパターン認識的な機構が働いているのだろうと思う。コードを眺める。妙に気になる部分がある。良く見ると間違っている。ただそれだけだ。

初心者から見ると驚異的な特殊能力に見えるだろうが、実際には単に熟練の結果であって、特殊能力でもなんでもない。経験を積めば、誰にでも習得できるものだと思う。

日本語で書かれた書籍があるとしよう。プログラミング言語の入門書あたりがよいかな。この書籍に書かれている内容を、可能な限りすみやかに頭に入れる必要があるとする。皆さんはどうするだろうか?多くの人は 斜め読み という奴をやると思う。

ページを開く。パッと全体を見る。重要そうなことが書いてる部分だけをちょっと読む。本当に重要だったらその周辺を少しちゃんと読む。重要でなかったり知っていることだったら、読み飛ばして次に重要そうなところを探す。うまく斜めに読めれば、1ページを10秒程度で読めるだろう。300ページあっても合計 3000秒だから、1時間以内でざっと内容を頭に入れることができる。

これは凄いことだ。日本語の文字や文章をきちんと読んでもいないのに、何が書いてあるか、だいたい頭に入れることができる。日本語を勉強し始めたばかりの外国人には、手品か魔法のように見えることだろう。

コードをパッと見て誤りがわかってしまうのは、コードを斜め読みしているのと本質的には同じことだ。本の斜め読みなんて、日本人ならば大抵の人はやっている。日本語の斜め読みができるならば、コードの斜め読みができたっておかしくない。

では、一体どうやって日本語の斜め読みを習得したのだろう?日本人だから当たり前?その通り。日本人だから当たり前。日本語を読んで、日本語を書いて、日本語で考えて、日本語で喋って、日本語を聞いて、日本語漬けでン十年。そのくらいやれば斜め読みくらいできるようになる。

コードを読んで、コードを書いて、プログラミング言語で考えて、プログラミング言語で喋って?ン十年になれば、コードの斜め読みだってできるようになって当然ということだ。

パターン認識

日本語を斜め読みする時は、無意識に”この辺が大事かも”とあたりをつけて拾い読みしているはずだ。では、どうして”この辺が大事かも”と感じるのだろうか?まずページ全体を画像として捉える。すると、なんとなく目立つ部分がある。太字になっているキーワードだったり、特徴的な漢字の熟語だったり、箇条書きの黒丸だったり、特徴的な字下げだったり、空行で挟まれたブロックだったり。

斜め読みするには、こういう画像的に目立つ文章の構造や特徴点がまず重要だ。目に付いた構造や特徴点を中心にして、その前後を”ざっと”読む。

“ざっと”読むとは?一字一句を正確に音を想起しながら読むのではなく、ざっと読む。良く見る単語、特に漢字の熟語や文頭・文尾の定型句的な言い回しなどは、いちいち音を想起したりしない。パッと見て自分の知っている文字列パターンと一致していれば、意味だけが表層に出てきて音は省略する。

結局、日本語を斜め読みするということは、高速パターン認識を階層的に実行しつつ意味の連なりを記憶に残す、という行為だと言える。

しかし、これがうまくできるようになるためには、日本語の文字や言い回しや文書構造について、多くのパターンとその意味や解釈のデータベースが構築されていなければならない。普通に日本人を十年くらいやっていれば、相当量のデータベースが構築されているはずで、斜め読みもできるようになるというわけだ。

プログラムについても同様のことが言える。プログラムの構造や字下げ、変数名やマクロの目立ち具合、制御構造の特徴的な書き方、良く出てくる定型処理的な記述など。そういうものが頭の中で大量にデータベース化されていれば、プログラムの斜め読みも不可能ではない。

日本人であれば、日本語の書籍はどんなものでも的確に斜め読みできるか、というとそいういうわけでもない。斜め読みしやすい書籍もあれば、しにくい書籍もある。一般的に、説明的な書籍は構造がしっかりしているので斜め読みしやすいが、文学的な書籍は視覚的な構造があまりないので斜め読みしにくい。また、説明的な書籍であっても、まとめ方が悪ければやっぱり斜め読みは難しい。

プログラムはそもそも存在意義からして文学的ということはなく、いずれも説明的であるから、慣れてしまえば斜め読みはしやすいはずだ。ただし、まとめ方が悪いと難しいのは同じ。つまり、プログラムが関数やブロックや制御構造にうまく分割されているか、分割されていることが視覚的にわかりやすいように字下げや行分割ができているか、ということだ。

加えて、文章で言うところの文頭・文尾の慣用句とか定型の言い回しに相当するもの、たとえば条件判断文の書き方とか、計算式の書き方とか、変数名の付け方とか、そういったものが一定のパターンを持っているかがポイントになる。

これらは、コーディングスタイル (またはコーディングルール)と呼ばれているものとほぼ一致する。視覚的にわかりやすく、一貫性を持ったコーディングスタイルで書かれたプログラムは、斜め読みがしやすく、理解するのも早いし、混入した誤りを見つけるのも早い。そういうコーディングスタイルを身に付けて、常に実践するよう心掛けるのは大切なことだ。

注釈

  • 初稿に由来する表現の差異、ならびにWeb掲載に伴う修正のため、雑誌掲載の内容とは一部文章等が異なることがあります。
  • 転載許諾を頂いた株式会社KADOKAWAアスキー・メディアワークスブランドカンパニーならびに旧『UNIX Magazine』編集部の皆様に深く御礼を申し上げます。

著者プロフィール

tom

当社設立直後に入社して約30 年、UNIX の移植、日本語化、デバイスドライバ開発、周辺機器ファームウェア開発などに継続的に携わり、現在も現役でUNIX 系OS の移植、改造などの開発業務を行う。社内でもっともプログラムを書いている人の一人。代表取締役社長。

記事一覧Index