netcdf-ffc5, netcdf-ifc9, netcdf-g95 とも, これまで通り, static ライブラリのみを作成する.
wa_module.f90 に以下の行を足してコミット.
public :: rn, irm
マイナーバージョンを上げて, リリースする.
その他 2006 年度末に話し合った内容に関しては, 天文台モデルミーティングログ 2006/12/25-27 を参照のこと.
AssertEqual の解説文章に関して以下のように修正
Usage の「もしも answer と check の値, もしくは配列のサイズが 異なる場合, テストプログラムはエラーを返して終了します.」 の直前に「正答の場合は OK と表示する」などと記述する.
日頃のモデルの開発やその公開に関して, 何か面倒だなぁ, と思っていること いろいろ. ブレーンストーミング的に (だからどうする, はあまり深刻に考え ずに).
情報提供: 杉山氏
以下は,
に関して, ざっと読んでみて面白かった, 役に立ちそうだったことなど を石渡氏にざっとレビューしていただいたもののメモ書きである.
下記のメモに関しては石渡氏, 森川の不理解により, 分かりづらい, 紛らわしい, 間違っている記述があることを了承されたい.
プログラミングを始める時には, C, Fortran 等の機械言語で記述するより 先に, 自然言語による擬似コードを記述すべき. 機械言語は, その擬似コード をコメントアウトしつつ, そのすぐ下に追記する形で記述していくべき. 結果的にその擬似コードがドキュメントになる.
考察 (?): サブルーチンなどの言語単位の要約としての擬似コードは良いが, 各一行一行のコメントは後で変更するとき余計では??? (書き換えコストが 2 倍になる恐れがある).
個々の変数の「寿命」は短くする. 変数の定義された部分から変数の使用終了するまでを短くする.
あまりに短い名前はつけない. 記述的な名前をつける. ただ, その手法でやり続けると, 長くなりすぎるため, ある程度長くなったら適度なところで短縮することも大事.
マジックナンバー (12 月の '12' なども含む) をそのままコードに 埋め込むことはせず, 名前付き変数に置き換える.
一方のプログラマがキーボードでコードを入力し, もう一方のプログラマがミスに目を光らせ, コードをチェックする.
ある程度のマンパワー (少なくとも, 1つのプロジェクトに 2 人以上のプログ ラマ) が必要となるが, コードへ埋め込まれるバグが減る, お互いのプログラ マが鍛えられるなど, 良い点が多い.
if などの条件分岐がプログラム内にある場合, テストプログラムは全ての 分岐に関してチェックしなければならない.
リスト22-3 を例にとると, Condition 1 と Condition2 の両方に関して 真偽の場合のテストを行わなければならない.
「1つ違いエラー」のチェックを行うテスト. ある境界があったら, その境界の一つ前, 境界自体, 境界の1つあとの値を与え, チェックを行う.
テスト自体は自動化して行えるようになっていなければならない.
自動化できないのであれば手間がかかるだけなのでやらない方が良い.
ソースコードを組みなおす際には, 組み換えのコストが組み替えた結果得られる 利益よりも小さいことをちゃんと考慮する.
パフォーマンスを気にするのは最後の最後でよい.
考察 (?): 我々 Fortran ユーザの場合, これは真なのか疑問.
プログラムサイズが大きくなるとプログラマの参加人数が多くなるため, コミュニケーションが大変になる. ちゃんとルールを決める必要が出てくる.
プロジェクトになると, 結局大事なのは人と人とのコミュニケーション.
「コンストラクション」= プログラムを作ること (= コードを書くこと, 仕様 を考えること, リファクタリングすること)
コメントを書かねば分からない部分は, まずコードがもっと読みやすくならな いか考えてみる.
