「CasioBasic入門」シリーズは、改めてキチンと勉強する良い機会になっています。構造化プログラミングについて、チラッと触れたのですが、改めて整理をしてみます。高級言語が使われるようになって、ソフトウェアの生産性と品質が向上してきました。時期を同じくして、ソフトウェアの需要が増加したため、生産性や品質の向上が追いつかなくなりました。通して知っていました。この当時は、アセンブリ言語がプログラミングの主流でした。この言語はプロセッサの動作に近い命令を記述するものなので、ジャンプ命令が非常に多く(gotoの嵐と言っても良い)、プログラムコードからプログラム動作を理解し解析することが簡単ではありません。プログラミングは工芸であり、匠の技の世界でした。作ってみて動かして、不具合が見つかったらそれを直すと言う方法では、生産性や品質の向上は容易に進みません。Programming)と言う概念が出てきました。プログラミングの匠が活躍していた時代に、生産性と品質の向上を目指した新しい考え方「構造化プログラミング」は簡単には受け入れられませんでした。パラダイムシフトの前には必ず旧来の考え方との激しい争いがあるのは、いつの時代でも同じですが、当時も大論争が勃発しました。それでも、世の中はより良いプログラムをより多く必要としていたわけで、それに応えてゆく必要はあり、それが新勢力と旧来勢力の共通目標ではあったのでしょう。両者が歩み寄ることが出来ました。この説が最も説得力があり、現実的なように思われます。ここに落ち着くまえには、2つの重要なポイントがあるとの指摘があります。提案された「構造化定理」これは、どのようなプログラムでも、下図に示すような、連結(Concatenation)、選択(Selection)、反復(Iteration)の3つで表現できると言う数学理論です(引用)。なくてもプログラムを作れると言うことを言っています。それ以上でもそれ以下でもない、単なる数学理論です。この理論が出された時は「構造化定理」とは呼ばれておらず、goto使用禁止を唱える人たちによる命名と言う話もあります。言う和訳も見られます。送られた書簡で、書簡のタイトル「goto文は有害である」通りに、極めてストレートにgoto文の使用禁止を主張するものです。goto文を使うと、プログラムは簡単にスパゲティ構造になり、これには異論の余地はありません。これが大論争に油をそそいだようです。なると、どこまで行っても平行線、宗教論争の様相であったに違いないと私は思います。goto文を使ってプログラムを作っていたプログラマが、いきなり使うなと言われても、そう簡単に受け入れられるものではないことは想像に難くありません。(Dijkstra)の名前が必ずでてきます。それくらい根源に迫る劇薬のようなものなのだと思います。やむなし、と言う大人の議論だと思います。支持するものでもあります。goto文を使うと、あとで絶対に自分の首が絞まります。使っても良いと自分で決めています。ジャンプ先が、必ずエラー処理や例外処理になるので、むしろプログラムの流れが明確になる利点があります。Knuthの論文が受け入れられた歴史的事実を知ることは、考え方に幅を与えるものと思います。今では、構造化プログラミングは空気を吸うくらい当たり前になっているのでしょう。普通にC言語を使えば、自然にこの手法になります。構造化プログラミング言語として作られているので当然なわけです。使っていて、外から見えないだけだと言えます生業としてのプログラミング経験の無い私の目には、goto是非論争は子細なことのように映るのです。構造化プログラミングは、「読んで分かりやすいプログラムを書こう」という目標で、以下の方針でプログラムを作ることです。構成されるブロックを作る。このブロックは出口と入り口が1つだけでなければならず、ブロックの連結でプログラムを構成する。