昔々の話になるのだが、
ごく初期のROM-BASICの時代には、行番号を付してのプログラムの記述が原則で、
GOTO文で行番号宛てに処理を跳ばすという技法が当たり前だったのだが、
そうこうしているうちに行番号を使わないプログラミングができるBasic言語が登場して、
それでうまくいけるんだろうかと心配したのだが、
Labelを使えば従前と変わらないということになった。
しかしながら、GOTO文を多用すると、
当初は自分ではその論理プロセスはよく分かっていたはずのものが、
しばらく日を置いてプログラムを見直すと、その論理プロセスが良く辿れないという、
そういう「苛立ち」を味わう羽目に陥る。
いわゆる「スパゲッティ・プログラミング」という、笑い話になったのだった。
GOTO文をできるだけ使わないようにプログラミングを行うために推奨されたのが、
制御構造文を使いこなすということで、
もっとも効果的なことが、
IF ~ THEN ~ ELSE文で処理を分岐させる場合に、
選択された処理ごとにずらずらと処理ルーチンを記述するということは、
一見して分かり易いように見えながら煩瑣な処理になりやすいから、
SELECT CASE文で事例ごとに処理を独立させて記述するということで解決できる。
私にとっての構造化プログラミングへの「入り口」であり「端緒」だったのはここであった。
構造化プログラミングという技法は、
いろいろな技法が提唱されているようなのだが、
私の理解では、
個々の処理(関数なり手続き)の徹底した「部品化」であって、
この部品を組み合わせて1つの一貫した処理にするというのがメイン・ルーチンの役割であるという、
そういう見通しを立ててのプログラミング技法であると理解している。
もちろん、このような見方はプログラミングの世界での特有のものではなくて、
私らのようなモノづくりに従事している職人の世界では、
製作過程での個々の段階で確実に加工がされていることを確認して、
次の工程に進むという手順なのだが、
そのことによって、最終的な製品の品質が保証されるということになっている。
モノづくりの世界での品質保証の考え方が、プログラミングの世界にも適用されたものと、
いうことなのだろうと考えている。
(この項は後に続きます)