VZEditor/Magazine/CJ1.md

# 楽しいプログラミング 《第1回》

## ■ はじめに
 この本を読んでいらっしゃるからには、おそらく貴方はプログラマ、それも相当腕の立つCプログラマでしょう。そんな方々が読んで得するようなテクニックは、残念ながら私には思い当るものがありません。かれこれ2年以上もCを使っていないくらいですから。さて困った。一応連載を引き受けてしまったからには、何か書かなくてはならない。ふむ。やはり今まで自分が書いてきた物、考えてきた事を書くしかないな。

 プログラミングは、それ自体大変楽しいものです。えっ、楽しくない？　それはいけない。納期に縛られ、仕様を課せられ、チームを組まされ、そんな中で歯車の一部と化したプログラミングは、確かにつまらないものかもしれません。幸か不幸か、私はこれまで一度もそういう経験をした事がありません。いわば、「おめでたいプログラマ」なのです。ですから、お読みになる方もその辺の事情はお察しください。

 私の知ってるコンピュータの世界は、極々狭い、MS－DOSの世界に限られます。UNIXなんて使ったことはありません。高級言語もCとBASIC（N88以前の）しか知りません。もちろん、プログラミングの教育を受けたことも、アルゴリズムの勉強をしたこともありません。そんな事を鼻にかけるつもりも毛頭ありませんが、というのも、私は常に「ソフトウェアを作る事」を目的とし、「プログラミング」はあくまでその手段にすぎない、と考えてきたからです。「インベーダーゲームを作りたい」、そのためにワンボードマイコンを買い、アセンブラを憶えたのです。「98でゲームを作りたい」、そのために86のアセンブラを憶え、エディタを作り、Cを憶えたのです。しかし、その「手段」や「道具」の中に、並々ならぬ思い入れが生じた事も否定できませんが。

 元来、プログラミングという孤独な作業は、精根こめて物を造る職人の心に通じるものがあります。より速く、より短く、より美しく。そして、より素晴らしい物を。これらの押さえ難い衝動を持たぬ者に、どうして真のソフトウェアが書けましょう。そして、その向上心ゆえに、楽しさも生まれるというものです。

 というわけで、この連載は「楽しいプログラミング」と題しました。いったいプログラミングのどこがそんなに楽しいのか。もっと楽しくプログラミングするにはどうするのか。そんな事を気ままに書かせて頂きます。いつまで続くか判りませんから、言いたい事はなるべく早目に書いてしまおっと。それでネタが無くなったらその時はその時・・。

## ■ プログラミングの掟
 いわゆる「いいプログラム」を作るにはどうすべきか。この方向性だけは、言語の種類やハードウェアに寄らず、普遍性があると思います。思いあたるところを「7つの掟」としてあげてみました。

1. アップデートが容易になるように書く。
2. 視覚的な読み易さを配慮する。
3. モジュール間の依存関係を明確にする。
4. 物の性質に即して表現する。
5. 重複した記述を避ける。
6. 固定部と可変部を分離する。
7. スピードとサイズを常に念頭におく。

 （1）が大原則です。プログラムはいわば成長する生き物ですから、修正と拡張の容易さが、そのプログラム開発の生産性を大きく左右します。(2)～(6)の掟も、結果的にはこの生産性の向上につながるものであると言えます。

 （2）は、インデントやスペーシング、コメンテーションのつけ方です。個人個人で、予めしっかりしたガイドラインを決めておくべきでしょう。

 （3）は、モジュール間インターフェイスの明確化です。通常コメントを書かない人でも、この部分だけはしっかりとコメントする必要があります。当然、モジュール間の結合は、可能な限り浅くしなければなりません。そのためのモジュール仕様の決定が、データ構造の構築と共に、プログラム設計最大の課題です。

 （4）は、「意味をもった数値を記述しない」、と言い換えることもできます。Cの型付き変数、構造体、enum、#define等を用いれば、ほとんどの場合、これを回避できるはずです。BASICとCの最も大きな記述上の格差も、この点にあります。

 （5）は、似通ったルーチンの羅列の排除・・究極的な処理速度の追及の為の意図的なコードの羅列を除き、無駄なコードサイズと修正の容易さを求める意味でも、なるべく1つのルーチンに統合すべきです。ルーチンの羅列に対して嫌悪感すら感じないようでは、もうおしまいです。もう一つには、Cの構造体どうしの重複した部分の記述があります。これはC++の継承を使えば、きれいに統一できますね。

 （6）の意味はちょっと掴みにくいかも知れません。要するに、メッセージやユーザーインターフェイス等のデータ部（可変部）は、できる限りコード部（固定部）とは分離すべきである、という事です。特に、大規模なアプリケーションになるほど、その必要性は顕著です。これを行なわずに全てをコード中に埋め込み、メッセージをちょっと変えたり、表示座標をちょっと変える度に再コンパイルしていたのでは、たまったものではありません。GUI（Graphic User Interface）ベースのアプリケーションでいうところの「リソース」が、まさにこれに当ります。できうれば、リソースはユーザーサイドでカスタマイズ可能であるべきでしょう。

 （7）だけが、それ以前の掟と相反関係にあります。というのは、（1）～（6）がプログラムの生産性を指向するものであるのに対し、（7）はプログラムの性能を指向するからです。大抵の場合、これらは両立しません。また、（7）でいうところのスピードとサイズも、しばしば両立しません。これらをいかにうまく調停するかが、最終的にプログラマに求められるセンスと言えるでしょう。

 以上の掟は、いわば根底に流れる信条ですから、この上で、実践に応じたテクニックを磨かねば、いいプログラムには成り得まえん。そしてその上でさらに重要なのは、「いいソフトウェア」を作ることです。幾ら苦心してプログラムを書いても、それが誰にも使われなければ、単なる自己満足に過ぎません。

 初回ということで、やや抽象論から入ってしまいました。次回はちょっと視点を変えて、現状のC／C++言語の不満な点などを考えてみます。

（雑誌「**PC POWER** 1992年7月号」掲載）