文書的プログラミングとは？

プログラムなんて簡単さ、分解の仕方が悪いんだよ。

NetNews発言を再編集しました。
fj NetNews--> fj.comp.lang.c , fj.comp.lang.c++
文章の繋がりが変かもしれませんが想像力でお読み下さい。

コメントが無くてもプログラムが文章になっている。（しかも美しい）

例えば、1行しか処理が無い命令でも関数にする。
例えば、コンパイル後のオブジェクトを想定する。
#こういう事が出来ていないから悩むのです。
このような配慮が文章のようなプログラムになります。
これがきちんとしていれば、日本語でも英語でも関係ありません。

仕事でプログラムする場合には、細かい規約を決めてあげます。
こうすることによりシステムの統一性を保持し、各プログラマーの個性を消します。（でも基本は上記の通りです。難しくないです。）
なぜなら仕事のシステムは、設計者の意図を反映するものでプログラマーは命令通りコーディングすれば良いのです。
#もちろん中間の設計者と規約に付いても話しますが。
設計者が日本語でシステムを文章のように噛み砕けば（能力があれば）、以降の作業は翻訳だけなのです。
#まぁ変な設計者に着いたら大変ですけど。

関数群と言うのは全て同一ファイル（ソース）から導かれることを保証することです。
つまり、関数と言う単位は重要でなくソースファイル単位が重要なのです。
C++で言えば1ソースファイルをクラスとみなす。
「関数群で意味付けする」を間違って理解してはいけません。
同一ファイル->OBJ->ライブラリがCの環境制限です。（OBJは物理的に閉じたほうが良い）
これを無視するとバグだらけのまとまりの無いシステムになります。

と言ってまだコンピュータは会話のような文章でシステムを記述するにいたっていません。
「現状では、何々（の中の何々）をどうする」の連続でシステムを記述することが近道です。
すると、最初の何々は名詞的（何何するもの）になり、構造も完全に閉じていなければ行けません。
そして、閉じさせる有効な手段は「C言語では」ファイル単位で設計。C++ではクラスになります。
#ここの記述を理解してもらえないと単なる関数論になってしまうなぁ。
#これが理解できれば以降は単語の順番と言う問題であることに気づきます。（自分で決めれば良いこと）

簡単な例では、「通信するものTuusin.c」はコンパイル後のOBJで閉じていることを保証してプログラムする。その結果が関数群と呼ばれるものになっている。（つまり必然的）
できたOBJの中には通信バッファ等も閉じて網羅されている。
Tuusin1.cの中にTuusinSend()があって、Tuusin2.cの中にTuusinWrite()があってはならない。
この例では文書的なプログラムは崩壊します。（できているようで実はできません）

そして、Tuusin.cの大部分は意味付けされたstatic関数で構成されており、関数を積み木のように積み上げextern関数ができる。
#私は小さい部分での文書化プログラムと呼んでいます。

次にいくつかのファイル単位で積み木のように構成されたちょっと気の利いたファイル（ソース）。
#私は大きい部分での文書化プログラムと呼んでいます。

つまりミクロ（関数の内部）からマクロ（ファイル単位）まで一貫して「何々（の中の何々）をどうする」でシステムを記述する。

「何々」の名前さえ付けば、「どうする」のレパートリーは少ないのでパターン化できます。
これは皆さんご存知の通りです。

#長々書くより、C言語でカプセル化と抽象化をするのには、ファイル単位でするのが常套手段と言った方が良かった気がします。
#後は簡単なルールがどこかにあれば文書のように記述できるし、まして関数名で悩むなんて…。
#そして、関数の再入を保証した構成にすれば文書的なプログラムが崩壊しない（特例の排除）。と。

ここからが本題だったりする。

桃太郎.c
桃太郎を初期化する。
桃太郎を歩かせる。
桃太郎に手渡せさせる。

犬.c
犬を初期化する。
犬にしゃべらす。
犬に受け取らせる。

演出.c
演出を初期化する。{
　桃太郎を初期化。
　犬を初期化。
}
演出の家来編を演出する。{
　桃太郎を歩かせる（スキップ）。
　犬にしゃべらせる（団子くれ）。
　桃太郎に手渡せさせる（団子1つ）。
　犬に受け取らせる（団子1つ）。
}

桃太郎劇.c（システム）
劇の初期化{
　舞台の初期化。
　演出の初期化。
}
劇の開演{
　演出プロローグ編。
　演出家来編。
　…
}
以上はファイル単位での文書化。
関数内部も基本的にこのように作る。

この「桃太郎劇」をどの文体で翻訳するかはチームで決めれば良い。
ここまで来れば関数名で悩むことはないと思う。
おそらく以下の決め事が妥当になると思われます。

extern ソース名+動作名+[補助名]( メッセージ );
ソース名＝通常コーディング前に決まっているはず。
動作名＝経験からパターンはそんなにない。(Get,Put,Check)
補助名＝悩むとすればここ。
これをmomotaro_InitにするかMomotaroInitにするかはシステムを作る人の好みでしかないと言うことです。
重要なのはプログラムを文章のように分解できるか、コーディングが文章のようになっているか、なのです。
慣れるとリアルタイムにコーディングできます。

ここで、カプセル化と抽象化を考えるを読むと更に理解が深まります。

本当は私も「文書的」と言わないです。

構造化プログラムを進めて
カプセル化と抽象化を意識した設計・プログラムスタイルが文章のようにわかりやすい（制作しやすい）ソースを書けると言うことでした。
その副産物が結果として関数の名付けに反映されている。

後の人が読みやすいとか整理に適している理由が最初にあって関数名が付けられる事を危惧しました。
Sample1.c内にsample_init、Sample2.c内にsample_termがあってはいけない。
プログラムは最終的に動くと思うが、バグの原因にもなります。

また、人間にとっても分類されているように感じますが、実は関数をソートしただけに過ぎません。
「文書」とあえて言うのは、ソースの中に「連想」と言う、本来人間が自然に分類する能力を織り込ませる目的があります。
結局、ファイルと言う単位が暗黙のキーとなるなら、ソースを読むとき、書くときの連想の助けになります。
その結果が「オブジェクト指向」に向かったのは、やはり必然的だと思います。

#オブジェクト指向（例えばC++）に移行できないプログラマが多くいます。
#Cで関数をサブルーチンと思っている人やソースファイルを単なる関数の保管場所と思っている人、プログラムの途中で当初予定に無かったif文が出てしまう人、などなど。
#コメントが異常に多いのも信用できません。
#debugをするときプログラムの修正をしてコメントの修正をしていないソースが多いのです。後から見ると罠にかかったように感じます。
本当にプログラムできる人（向いている人）とは、設計とプログラムを同時に一人で行う場合にはっきりします。
結局、机上で「あれこれ」するより、「プログラムしちゃえ」と言うケースで「その方が早い」と言う自信があるとき（人）です。

そして、その人はリアルタイムコーディングできるのです。
しかも同時に文書みたいなコーディングになっていると思います。
#こういう人を見て考えなしに「自分もできる」と思いコンピュータの前でエディタを開く人も多いのです。（端から見ると作業しているように見える）で、出来たのがスパゲッティー。ちょっと変わった操作をすると落ちちゃう。

仕事でも状況は同じで、できる人は打ち合わせに資料を書くのが面倒なので、プロトタイプを持参するときが多いです。
その方が受けは良いし、問題の把握も容易です。
#でもやりすぎると工数の足元を見られます。

しかし、これだけは言えます。「使うプログラマの個性を消す」と言う重要性。
手塚プロのアシスタントが個性を出したら手塚漫画でなくなるのです。
「できる人」はその中でも頭角をあらわし、寺沢武一になるのです。
プログラマは職人であると思っています。
職人が弟子を育てる一番良い方法は古来から何ら変わっていないのです。

戻る