基本方針 Fortran

プログラムを読みやすくし,間違い・条件設定等のミスを減らすためのメモ. あくまで個人的な見解です.
効率的に開発をし,無駄な時間を減らせるよう心がけたい.

implicit none を使用する

  • 暗黙の宣言の場合,変数のスペルミスをしても気づきにくい. 使う変数は全て宣言した方が他人から見てもわかりやすい. VBA の Option Explicit も同じ.

変数名をわかりやすく&1文字にしない

  • 例えば水位を H,流量を Q などとして,算出の過程で生じる中間値の変数を HH,QQ や H1, H2 などと名付けてしまうと,他人から見たらよくわからない.一時的なものにはそれがわかるように,tmp とか wrk とかをつける.
  • また上記のように変数を1文字とすると,デバッグ段階で変数を検索するときに見つけにくく,効率が悪い.
  • ループで使う i, j, k は慣習的にも1文字で良いかも.その他は避ける.

定数の入力に namelist を活用する

  • 定数を外部から値を読み込むことで汎用性をもたせる.
  • 格子数,計算ステップ数は namelist を活用すると手間が省ける.
  • ただし,重力加速度,円周率などいずれの計算においても不変(とみなす)ものについては namelist を使ってはいけない. テキストファイルの編集ミスで思わぬエラーが出たり計算が破綻したり...というリスクを回避するため.

subroutine 内で intent を使う

  • 引数が他の値の算出に用いられるだけなのか,値が変わって subroutine から出て行くのか,ハッキリと示すと後から整理がしやすい.
    real*8, intent(in) :: hoge
    real*8, intent(inout) :: huga
    などと書く.引数全てに intent をつけることで,引数と local な変数(subroutine 内でのみ使う変数)の区別が容易につく.

係数はルーチンの冒頭部に定義する

  • プログラム中盤の計算部分に 12 や (1/3.6) と書かれても,何の根拠に基づいた数値かわからない. alpha, beta や coef1, coef2 (coefficient の略)として,メインルーチンやサブルーチンの冒頭部で設定してしまいたい.
  • 計算式中に出現しても良い数字は,整数の1~4くらい.
  • ただし,差分法において生じる係数(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 なせいでできない...ということがありうる.

Front page   Edit Diff Attach Copy Rename Reload   New List of pages Search Recent changes   Help   RSS of recent changes
Last-modified: 2018-08-06 (Mon) 15:28:59 (565d)