またプログラムを自分で書くときには、極意があります。参考にしてください。

後輩が財産として使える物であること。

1. 作られた directory には README という file があって その中には、その directory が 何のソースプログラムが格納しているかを 示します。
2. README には 各 file の名前 とその簡単な説明が必要です。
3. 説明には、目的と 入出力 file 名と、実行方法も説明されています。
4. 最終的に library として、WWW に登録しやすいように、各 file の先頭部分にはコメント文として < PLAINTEXT > を入れます。

   誰が作った物であるか、どうやって実行できるかわかること。

5. 各 file の先頭部分にはコメント文として必要な情報が入っていなければいけません。必要な情報とは、
   1. 制作者名、制作日時
   2. プログラムの名前、入出力 file 名、実行方法
   3. version
   4. 関連するプログラムの名前 (関数名、subroutine 名、親プログラム名、 子プログラム名)
   5. 重要な変数名

   誰がみてもわかるプログラムであること。

6. 変数名(directory, file 名) は、内容がわかる物でなければいけません。 最も 親 directory 名の名前は、言語に関連した (for, c, tex, vhdl, xfig, maple, perl) 名前で なければいけません。
7. 定数として用いられる変数は、全て プログラムの先頭に記述していることが必要です。
8. 1 つの ソース プログラム( 1 つの subroutine, 1 つの関数) は、200 行を超えてはいけません。適当に分割して独立して使いやすい物にします。 但し、プログラムの性質上 explicit に関数を記述するような場合は除きます。
9. 変数名の長さは、プログラムの中の10 行以内で独立に使うものを、 1 文字 (i,j,...), 20 行以内で独立に使うものを 2 文字 (i1, i2, etc) プログラム全体に渡って使うが非常に頻繁に使うものを 3 文字, common 変数は 6 文字、というように文字の長さがその性質を示すように設定する。
10. プログラム におよそ 10 行ごとに コメント文を入れ文字で説明する。 また 2-8 行ぐらいで、見やすいように空白行を入れる。
11. コメント文を入れ文字で説明するとは、その部分の機能を説明し、また 重要な変数を説明することである。
12. fortran の場合には、implicit real*8(a-h,o-z) を使用する。 複素数を使う場合には、implicit real*8(a-h,o-y), implicit complex*16(z) を用いる。複素単位は zi=(0.0d0,1.0d0) を用いる。
13. fortran の場合には、実数には必ず 小数点 . をつけ、最後に d0 をつける。
14. fortran の場合には、定数は parameter 文にする。各 subroutine に共通の parameter 文は、include 文で 共通の parameter file を読むようにする。

    プログラムを書くときの極意

15. 上のルールを守って書くこと。ルールを守れば、プログラム の記述の良し悪しはまずは、問わない。正確に動くことこれが良い プログラムの基本である。
16. 動作確認ができたら、次に簡単な記述、明快な論理にめんど くさがらないで直すこと。前のプログラムを残しておき、同じ結果 が出ることを確認すること。大きなプログラムになってから、論理 を簡潔に直すのは難しいので、出来る限り早い時点でこの問題を考 えなければならない。
17. まず簡単な動作確認をしてから、一歩一歩複雑なプログラム にすること。一度に難しいものを組むと、どこが間違っているかわ からない。
18. プログラムがいろいろな入力に対し確実に動作するためには、 parameter の上限など、プログラムが動くのに決定的なことは、if 文でプログラムが警告をだして終了するように、安全装置をつける ことが必要。ただし if 文は for (do) などの繰り返しの中におい てはいけない。実行時間が遅くなる。
19. 実行中のデバッグの基本は、エラーをおこしているところで の変数を全て表示させることである。
20. 1 歩前進するときは、必ず前のプログラムを保存すること。 保存では、プログラム名+日付 の file 形式 (model-010524.f) が 良い。 そして、プログラムの先頭に コメントとして何を変えたか 更新記録をつける。作業の修了時に、次にどこを直すかを記録すると 次の作業の時にわかりやすい。
21. ある程度進んだら、一度印刷してプログラム全体の構成で無 駄が無いか? 考えること。前に進むのも大事だが、整理してから進 む方が進行がはやい。ライブラリー化をすることは、大変良いこと である。全体の点検修理は難しいが、部品の改良は簡単であるから である。
22. 完成したプログラムを解読するのは難しい。順番に成長していった 過程のプログラムを順番に公開しておくこと。後輩が知りたいところを 短い時間に知ることができる。

naka@tube.ee.uec.ac.jp