基本方針 Fortran †
プログラムを読みやすくし，間違い・条件設定等のミスを減らすためのメモ．
あくまで個人的な見解です．
効率的に開発をし，無駄な時間を減らせるよう心がけたい．
implicit none を使用する †
- 暗黙の宣言の場合，変数のスペルミスをしても気づきにくい．
使う変数は全て宣言した方が他人から見てもわかりやすい．
VBA の Option Explicit も同じ．
変数名をわかりやすく＆1文字にしない †
- 例えば水位を H，流量を Q などとして，算出の過程で生じる中間値の変数を HH，QQ や H1, H2 などと名付けてしまうと，他人から見たらよくわからない．一時的なものにはそれがわかるように，tmp とか wrk とかをつける．
- また上記のように変数を1文字とすると，デバッグ段階で変数を検索するときに見つけにくく，効率が悪い．
- ループで使う i, j, k は慣習的にも1文字で良いかも．その他は避ける．
定数の入力に namelist を活用する †
- 定数を外部から値を読み込むことで汎用性をもたせる．
- 格子数，計算ステップ数は namelist を活用すると手間が省ける．
- ただし，重力加速度，円周率などいずれの計算においても不変(とみなす)ものについては namelist を使ってはいけない (parameter で定義する)．
テキストファイルの編集ミスで思わぬエラーが出たり計算が破綻したり...というリスクを回避するため．
subroutine 内で intent を使う †
係数はルーチンの冒頭部に定義する †
- プログラム中盤の計算部分に 12 や (1/3.6) と書かれても，何の根拠に基づいた数値かわからない．
alpha, beta や coef1, coef2 (coefficient の略)として，メインルーチンやサブルーチンの冒頭部で設定してしまいたい．
- ただし，差分法において生じる係数(3/2, 1/6など)は，文字列にしてしまうと判読困難になるので，そのままでもOK．
配列が基本の変数は allocatable (動的配列)に †
- 計算領域が変化する場合に対応できるよう，動的配列を使用する．
real, allocatable :: hogehoge(:,:)
で宣言して，あとから
allocate(hogehoge(ny,nx))
とかするだけ．大した手間ではない．
- 古いプログラムでは，利用する配列より大きめに宣言するケースが多く見られるが，容量の無駄，美しくない，各次元の要素数が何に基づいているのかわかりにくい，といった理由からその都度修正していくべき．
- 現在も今後も，明らかに○○個(大抵2or3個)の配列しか必要としないだろう，という変数は別．
装置番号は I/O 別に開始する数を決める †
- 例えば input 用ファイルは11番から始め，output 用ファイルは51番から始める，とかとか．1桁の数字は混同する可能性があり，探しにくいので避ける．format で使用する文番号も同様．
類似変数を構造体でグルーピングする †
- 環境が似たような変数(同じ格子で構成されている等)は，bound%x, bound%y にした方が整理しやすい．
- いちいち計算式に bound%x と書くのが面倒と思われるが，主要な処理はどうせ subroutine 内で行うのだから，引数にすれば何度も使用することは避けられる．
go to 文の使用を極力避ける †
- 特に go to (hogehoge, hugahuga) のような記述は厳禁．編集時は良くとも，しばらく触れないと計算フローを追えなくなる．開発した人以外にとっては非常にわかりにくい．
- format 文で文番号が必要なため，使わずに済むものは使わないほうが良い．
- do ループの中でgo to と continue を使って次のループへ…という処理は，cycle で代用可能である．
ENTRY 文を使用しない †
- 自身が ENTRY 文をよくわかっていないのが最大の理由．古いプログラムによく見られるが，計算フローを追うことが面倒なように見える．
COMMON文を使用しない †
- 他人のためにも，subroutine 内で利用している変数は明示した方が良い．
- COMMON 文を使用するメリットは，subroutine 内で変数の宣言の入力の手間が省けることである．しかし，subroutine と呼び出す routine で同一の変数名を扱うというのが汎用性を欠く．
- 同じ配列構造であれば subroutine の引数を変えるだけで同様の処理を行えるのに，COMMON なせいでできない...ということがありうる．
