疑似プログラム

コンピュータは道具です。古くからある単機能の道具と異なり、いろいろなことができます。ただし、それが可能となるのは人間が何の目的で使うか考え、さらにそのための実現手段を考えだし、それを正確に順序正しく命令としてコンピュータに与えたときのみです。そのとき、あいまいな表現は許されません。いままでの説明では、自分で考えることができないコンピュータに対して、命令を与える上で知っておかなければならないいくつかの基本的な要素について述べてきました。
ここでは、それらの要素を使って、ある目的を実現するための、手順、段取りを表現する、すなわち、疑似プログラムの記述の仕方の大枠を示します。そして、次の章では具体的な問題に対するプログラムを、その形で書き表すことにします。

• プログラム　　「○△□○△□○△□」
  
  定数
  Pi = 3.1415 : 実数型
  e  = 2.7182 : 実数型
  　　・・・
  　　・・・
  
  変数
  x, y : 実数型
  i, j : 整数型
    v  : 1次元実数型配列 [1.. 3]
    A  : 2次元実数型配列 [1.. 5 ; 1.. 3]
  　　　　・・・
  　　　　・・・
  
  
  {
  
  命令文1
  命令文2
  命令文3
  ・・・
  ・・・
  命令文x
  
  }
  

これをメインプログラムのひな型とします。
プログラム名は、これがなんのプログラムであったか、後になってもすぐに分かるようにするためにもなるべく意味のあるものにする必要があります。コンピュータにやらせる仕事の目的が明らかになった後、実際の処理の対象となる情報のデータ構造をどうするかという問題を考えなくてはなりません。それを解決したならば、すべてのデータを格納する変数を、そのデータ型と共に宣言します。次に、やらなくてはいけない処理を順に命令文として書き出します。メインプログラムにおける処理の記述は、大まかであるのが普通です。複雑な処理は、階層化することにより、関数または手続きとして呼び出します。

サブプログラムは、メインプログラムの後に続けて書くことにします。最初の段階では、サブプログラムの部分には仕様だけを記述する場合もあります。全体の見通しをたててから、その仕様に沿って詳細化を行うことを考えます。どの段階まで詳細化を行えばよいかは、状況によって異なってきます。最初からある特定の言語に直すことを想定しているならば、その言語の基本命令まで詳細化しなければなりません。このテキストでは一般的な数学表現のレベルでの詳細化を考えます。

何度も言ってますが、

ここでは、それらの要素を使って、ある目的を実現するための、手順、段取りを表現する、すなわち、疑似プログラムの記述の仕方の大枠を示します。そして、次の章では具体的な問題に対するプログラムを、その形で書き表すことにします。

それがそもそも大間違いだ、っての(苦笑)。
次に、ひな型である通大用語の「疑似プログラム」なんですが、本来疑似コードでは、

• プログラム　　「○△□○△□○△□」
  
  定数
  Pi = 3.1415 : 実数型
  e  = 2.7182 : 実数型
  　　・・・
  　　・・・
  
  変数
  x, y : 実数型
  i, j : 整数型
    v  : 1次元実数型配列 [1.. 3]
    A  : 2次元実数型配列 [1.. 5 ; 1.. 3]
  　　　　・・・
  　　　　・・・
  
  
  {
  
  命令文1
  命令文2
  命令文3
  ・・・
  ・・・
  命令文x
  
  }
  

横線引いた部分は「要らない」部分です。どう考えてもこれは「Pascalの流儀」なんで、この辺の宣言は「要らない」のです。大体、宣言やる限り、「その言語のデータ型を全部知らないとならない」し、かつ「他の言語でのデータ型が同じだ」と言う保証が無いんで、ポータブルじゃないんです。
もうこの辺は、例えばPythonやRubyを選んだ人は分かってきている、でしょう。ああ言う言語自体が構造的には既に「疑似コードである」と言う事を。

プログラム名は、これがなんのプログラムであったか、後になってもすぐに分かるようにするためにもなるべく意味のあるものにする必要があります

う〜〜ん、この辺りは「もっともだ」とは思うんですけど……。
いや、実は一概には言えないんですが、一般に「名前の付け方」ってのは大きく分けて2系統あるんです。これらは「コンピュータの発展」に寄与してきた2大潮流があったから、ですね。

• プログラムの名前を極限まで短く書く事を良し、とするAT&T方式


• プログラムの名前を親切に長く書く事を良し、とするMIT方式

もう一度解説しますが、AT&TってのはUNIXやC言語を開発した(本業は電話)会社で、彼らが「記号化と思えるほど短い」名前を付けるのを好みます。

短いと名前としては分かりづらくて良くないんじゃない?

と思うでしょう。確かにそうではあるんですが……。
一般に「良く利用する」プログラムだと、文字数が多いと「頻繁に呼び出すのがツラい」んですね。また、「長い」とタイピングミスを誘発する可能性が高くなる、んです。
例えば、どんなプログラムかは問いませんが「高校数学の窓」(Window of High-School Mathematics)と言うプログラムを書くとします。
このプログラム名として

whs

なんて言うプログラム名を付けるのがAT&T方式です。そして、別のプログラムでこのwhsを10回呼び出すにせよ、whsとアルファベット3文字を記述するのはそんなに大変ではありません。
実際、AT&Tで開発されたUNIXのコマンド(プログラム)名は、殆ど原型を留めていないくらい省略されています。それがまた初心者泣かせなんですが(笑)、一方慣れてしまえば総体的にタイピング量が減り、それはそれでとても有効なんです。
AT&Tの発想としては

人間は元来タイピングが嫌いである。

と言うアイディアが背景にはあるんでしょうね。
一方、通大のテキストに書いてあるような方式がMIT方式です。MITはLispを開発した世界最高峰と言って良い程の理工系大学なんですが、そのLispで使われている関数名は一般的にとても長ったらしいものです。
例えば、「高校数学の窓」(Window of High-School Mathematics)と言うプログラムを書くとすると、そのまま

window-of-high-school-mathematics

と名づけちゃうのがMIT方式ですね。
確かに「名前としては」分かりやすいんですが、逆に何十回もタイピングするとなると殆ど「苦行」です(笑)。また、タイピングミスも起こりやすい、って事は言えます。
MITの発想としては、

人間が全てタイピングする必要は無い。そう言うメンド臭い事こそ、コンピュータにやらせるべきだ。

と言うアイディアがあるようです。実際、MITはこの辺の「開発支援環境」の作成には定評があり、例えばwin辺りまでタイプすると「window-of-high-school-mathematics」をコンピュータが候補として返してくれる、いわゆる「入力補完機能」付きの開発環境作りはMITのお家芸で、事実上、これを倒したプログラムは存在しません。
一方、その「開発環境自体」が使うのが難しかったりして(笑)。いやはや、MITは一筋縄では行きませんよ(笑)。
まあ、いずれにせよ、「名付け方」はなかなか難しい問題です。
亀田の提案としては「名付け方」はある意味どうでも良いんで、どっちかと言うと「コメント」を丁寧に記述しておき、後で「コメント」を読んで「どんなプログラムなのか」分かるようにした方が良いかな、とか思っています。