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