Fortran by (Yutaka NAKAMA)

プログラムの保守性や移植性などについて

保守性について

１つのプログラムを２人以上で開発する時にはもちろんですが、自分一人でソフトを開発する場合でも、プログラムの書き方によってデバッグ作業のしやすさや開発速度等が変わってきます。また、開発環境や実行環境などによっても異なってきますが、とりあえず守っておいた方が良いと思われる事を箇条書であげてみました。

使わない方が良い文法など

【 GOTO文はなるべく使用しない】

GOTO文は多用するとプログラムの流れがわかりにくくなるため、なるべく使用をさけるのが懸命です。 (構造化定理が、任意のアルゴリズムは GOTO文を使用しなくともDO文やIF THEN ELSE文等で実現できる事を保証している) ただ、DOループから条件的に抜ける時などに、 (FORTRANには、C言語のbreak文に相当する文法が無いので) GOTO文を使用した方がわかりやすくなる事もあります。

【 COMMON文の使用はなるべく避ける】

COMMON文は異なるサブルーチン間で、記憶場所を共有する機能ですが、現在では、これを使用するプログラム方法は、危険かつ乱雑なもので、サブルーチンをCALLする時に引数の数を減らせる事以外は利点が無いという解釈が一般的です。デバッグ作業に負担が多くなり、変更がおきた場合に１箇所ではすまない等、保守性向上のためには、できれば排除した方が良い機能です。また、サブルーチンの独立性、汎用性が崩れ、ライブラリ作成の妨げにもなります。少なくとも汎用ルーチンには絶対に使用は避けるべきだと思います。

【 EQUIVALENCE文の排除】

EAUIVALENCE文は２つ以上の実体が同じ記憶領域を共有することを指定する文で、計算機のメモリーを節約するために生まれた機能です。以前、計算機のメモリー資産が少ない時代には有効な機能でしたが、これはきわめて危険な機能です。また、１つの領域を２通りに使いつづけなけらばらならいとしたら、プログラム修正は非常に困難になります。計算機の資源が豊富になった現在では、もはや時代遅れとなった機能であり、特別な理由が無いかぎり使用は避けるべきだと思います。

【 ENTRY文の排除】

この機能は、SUBROUTINE文またはFUNCTION文で代用できる機能で、規格の記述をかなり複雑にしてきた機能です。この文法を使用すると、プログラムの読者が、１つのサブルーチンでいくつもの手続きを定義しているかもしれないことを認識していなければならくなります。また、冗長かつ複雑な文法を理解している必要があります。このような文法を知らなくともプログラムは書けるわけですから、わざわざ使用する必要はありません。プログラムの保守性を考えると排除する方が望ましいでしょう。

【算術IF文の排除】

算術IF文は制御構造がわかりにくくなるため、絶対に使用は避けるべきです。 Fortran90では廃止予定事項となっているため、見つけたらすぐに書き換えましょう。

【実数型のDO変数の排除】

DO文のDO変数、反復の限界値、増分値には、整数以外に、実数や倍精度型の実数が使用できますが、実数には桁落ちなどが生じるため、反復を正確に行う事ができない事が少なくありません。この機能もFortran90の廃止予定事項に含まれています。

【同じ番号の付いたDO端末文の排除】

DO文は、２つ以上のDO文の終端を共有する事ができます。この使用法は、よく見かけますが、機能が増強されるわけもなく、思いがけない誤りを犯しがちであるという理由で、 Fortran90では廃止予定事項に含まれています。つまり見つけたらすぐに書き直す必要があります。これを使用すると、インデントのつじつまもあわなくなり、プログラムが読みにくくなるという事からも使用すべきではありません。
また、DO文の端末文にはCONTINUE文(またはEND -- DO文)を使用しましょう。 CONTINUE文またはEND -- DO文ではないDO端末文もFortran90の廃止予定事項に含まれています。これはプログラムを見やすくなるためにも必要です。
余談ですが、Fortran90では DO -- END DO 文が使用できるようになりました。 77の時代でもこの文法が使用できるコンパイラは多かったのですが、規格に無かったため、使用を控えている人も多かったのではないかと思います。この文法は結構便利なので、これからは使用する人も増えていくと思います。

【Ｈ型編集記述子の排除】

FORMAT文等、入出力の書式仕様を与える時に、Ｈ型編集記述子は使用はやめましょう。これは、プログラムを書く人がいちいち文字数を数える事を強要するため、プログラムミスの原因になるという理由で、 Fortran90の廃止予定事項に含まれています。文字列はアポストロフィ(`)編集を使用しましょう。

その他やっておいた方が良いこと

【インデントを積極的に使用する】

インデントを使用する事は、プログラムを見やすくするという意味で必要です。 FORTRAN66の時代では使用できなかったため、現在でもインデントを行っていないソースは多いと思います。しかし、F66からF77への移行は1980年代に終了しているため、積極的に使用すべきでしょう。
これまでインデントを使用した事が無い人は、かえってわかりづらいと思えるかもしれませんが、慣れるとそうでもありません。インデントを使用する方がわかりやすいという人の方が大多数をしめています。また、emacsのインデント機能は便利なので一度使ってみると良いでしょう。
Fortran90ではこれを進めたCのような自由プログラム方式となっています。しかし、FORTRAN77からFortran90への移行は始まったばかりで、いまだ77のコンパイラしか無い処理系が多いため、自由構文に移行するのはまだ速いと思われます。(1997年現在)

【ソースにドキュメントを入れる】

サブルーチン毎に、最低限、機能と引数の説明と入力であるか出力であるか等はコメント文に書いた方が良いでしょう。また、プログラムの作成者名と最終更新日くらいは入れておいた方が良いでしょう。

【変数名等を統一する】

変数名やその付け方を決めておくと、他の人が書いたソースが読みやすくなります。多人数で開発する場合には特に有効です。

【サブルーチンには配列の大きさも渡す】

汎用に使用するサブルーチンは、引数に配列がある場合、できればその大きさも渡した方が良いでしよう。これはデバッグ作業に役に立つ事があります。 (コンパイラオプション-Cやftnchek等で配列を壊していないかどうかがチェックできる)

移植性について

フォートランは他の言語に比べて移植性において優れている言語です。しかし、あるマシンでは動いたのに、他のマシンではコンパイルできないという事がおこる事があります。これはコンパイラのバグという事もありますが、コンパイラの拡張機能使用しているなど、ソースの書き方が原因である事の方が多いと思います。とりあえず守っておいた方が良いと思われる事をあげます。

【 FORTRAN77の規格にあわせる】

フォートランにはFORTRAN66,77及びFortran90などの規格がありますが、 Fortran90はまだコンパイラを持たない処理系が多いため、今は77の規格にあわせておいた方がいいでしょう。

【拡張機能を使用しない】

処理系においては拡張機能等の方言がありこれらを使用すると移植性が悪くなります。ただ、DO -- END DO 文は77の規格ではありませんが、ほとんどの処理系でコンパイル可能なので使用しても良いかもしれません。

【規格外の仕様は注意】

入出力文のように規格でも処理系ある程度自由度が認められている文法は、処理系によってことなる動作をします。これらに依存するプログラムは書かないですむ時は良いですが、どうしても書かざるを得ない時は、どの処理系でも同じ結果が得られるような書き方を経験的に捜す必要があります。