Fortran 95へのいざない（Fortran95移行ガイドーメンテナンスの観点からー）

「〜.f」から「〜.f90, 〜.f95」へ！

新たにコードを書くのなら迷うことなくFortran 95（以下F95）で書くべきです．これは，「コードは最新の規格で書くべき」と言う意味です．この文章を書いている間にもFortran 2003の規格発表が秒読み段階に入っており，F95も陳腐化することは言うまでもありません． 　問題は古いコード，特にFORTRAN 77（以下F77）で書かれたコードを今後どうするかということです．はっきり言って，F77コンパイラが無くならない限りは，F77コードは何も変更することなく問題なく動きます．当然ながら，F95のソースファイルとも共存できるわけです．また，言うまでもなくF95で完全に書き直すことはコスト面で現実的ではありません． 　しかし，少ない手間でF77コードをF95に移行することによって大きなメリットが期待できるとしたらどうでしょうか？　特に科学技術計算に供するコードは，修正が加えられ続けるものです．また，これらの作業は作者自身が永久に行うとは限らず，大抵は他人から他人へ受け継がれてゆくものです．コードが正確に動くことは当たり前ですが，加えてメンテナンスが容易である必要があります．これらが最小限の労力で実現できるのであれば，試してみない手はありません．簡単にまとめると，下記の２点を常に心掛けてコーディングをする努力が必要です． バグの入る余地を減らす（更新，コピペ等に強いコードを！） コードを見やすくする（機能，流れを分かりやすく！） 　本章はF77コードをF95に移行することによって得られるメリットを，特にメンテナンスという観点から説明し，そのための手順を示すことを目的としています．また移行は，少ない労力で段階的に行えるようにステップバイステップで示しています．基本的にはSTEP1さえ実践すれば，あとはどのSTEPからでも試すことができるようになっています． 　これを機会にメンテナンスを考慮したコード作成とF95への理解を深めていただければ幸いです． 　また，本ページは工事中です．いつ完成するかは分かりませんが暖かく見守って下さい…

吉田佳典

CONTENTS
STEP1	自由形式のススメ
STEP2	IMPLICIT NONEのススメ
STEP3	名前改善のススメ
STEP4	END DOのススメ
STEP5	COMMON「廃止」のススメ
STEP6	INTENTのススメ

STEP 1 自由形式のススメ

コードを見やすく，そして書きやすくしよう！

【このSTEPのポイント】

自由形式を使用する

【期待される効果】

コードが見やすくなる 　　　● 一行にたくさん書ける！ 　　　　　→ 気兼ねなくインデントできる！ 　　　　　→ コメントが書きやすい！ 　コードが書きやすくなる 　　　● 文番号位置，継続行記号位置指定の撤廃！ 　　　　　→ ６文字スペースとの決別！ 　バグの削減 　　　● 誤作動を防ぐことができる！

■ 固定形式がもたらす特有のエラー 　コードを作成する上で発生する最も多いミスは，言うまでもなくタイプミスです．これは例えばスペルミスという形で現れます．これらは丹念にコードをチェックすれば視覚的に見つかるものですし（エディタのカラーリング機能を使えばさらに分かりやすい），修正も簡単です．厄介なのは全角空白の混入などの見えないミス（これもエディタの不可視文字表示機能等で見つけることができますね）ですが，これらはFortranに限らず他の言語にも共通に起こり得ます． 　しかしF77の場合は,特有の固定形式というルールがあるためさらに注意が必要です．固定形式の概略は下記の通り． 固定形式の概略 行について 一行は最大72文字以内． コメント行について "C"または"*"で開始する行． 文番号について 行の1桁目（左端）から5桁目に記述． 文の継続について 継続行がある場合，２行目以降は６桁目に空白以外の文字を置く． 　文番号および継続文の記述について着目しましょう．記述が許されている桁数が規定されているので，これを必ず守らねばなりません．1文字でもずれると誤りとなります．文番号については桁を指定しなくたって構文解析で容易に判断できるであろうと考えられますが，几帳面に規定されています．また継続文については特に注意が必要で，１文字ずれるだけでエラーどころか誤作動してしまう可能性もあります．これはプログラム変更時のコピペ等で特に注意が必要となってくることを意味しています．これらはパンチカードでコード入力をしていたころの名残りであると考えられ，今日の開発環境からすればナンセンスこの上ありません． 　さらに，1行に許される文字数についてみてみましょう．はっきり言って，72桁というのはすぐに使い切ってしまいます．特に多重ループや入り組んだIF構文等で，インデントが深くなると顕著です．また，文番号や継続行を示す記号が一文字でも桁範囲を越えるとたちまちエラーとなり，その記号によっては誤作動を招きます．見た目が悪くなるので複数行に継続させたくないという気持ちが働き，インデントを抑制し，変数名を短くし，挙げ句の果てにはかえって見にくくなおかつメンテしづらいコードが出来上がってしまいます．また，72文字を意識しながら（数えながら）コードを書くのはなんとも精神衛生上良くないという問題を抱えています． ■ 自由形式がもたらす恩恵 　F90以降で（ようやく）採用された自由形式は，上記の問題を大きく改善してくれます．自由形式の概略を下記に示します． 自由形式の概略 行について ・一行は最大132文字以内． コメント行について ・感嘆符"！"で開始する行または完全な空白行（改行のみまたは空白＋改行）． ・行の途中に"！"があらわれた場合，これ以降から行末までがコメントと見なされる． 文の分割について ・セミコロン"；"によって，一行に複数の文を書くことができる． 文の継続について ・行の最後に"&"がある場合，文は次行へと継続する． ・コメント中の"&"は無視される． 　１行に許される文字数が132文字に拡大されたことは大変喜ばしいことです．17インチ以上のモニタが極々当たり前である今日では非常にリーズナブルであります．またコメントを文中に記述することができるようになり，例えば変数宣言文の文末にその意味を示すことができます．さらに，短い一連の処理等をセミコロンでコンパクトに一行にまとめることもできる仕様になっています．何よりも固定形式における文番号および継続文記述の桁指定に関するルールが廃止されており行の継続も簡単に行え，コードが非常に書きやすくなっていることが分かります．つまり自由形式の導入によって，コードにおける変更・追加やコピペに非常に強くなります．これからは，積極的に自由形式を取り入れましょう！ 　あと，一つのプログラム単位中での固定形式と自由形式の混合は許されませんので注意して下さい． ■ じゃあどうしたら良いのか？？？ 　ソースコードの変換を全て手作業でやるのは無理ですのでツールで自動的に行いましょう．例えばAlan Miller氏が開発したto_f90は下記のサイトから入手できます．ただし，誤作動することがあるので注意が必要です． http://www.csit.fsu.edu/~burkardt/f_src/to_f90/to_f90.html 実はこのツールを使うと，後述のSTEP4，５も終わってしまいます．

【具体的な方法】

コードを自由形式に変換する

STEP 2 IMPLICIT NONEのススメ

暗黙の型宣言は諸悪の根源！

【このSTEPのポイント】

IMPLICIT NONEを使用する

【期待される効果】

バグの削減・発見が容易 　　　● コンパイル時にミスタイプを発見 　コードが見やすくなる 　　　● 変数の型を簡単に確認できる

■ エラーが出ないという恐怖 　下記のコードをエディタにコピーして保存し，コンパイルしてみて下さい．何の問題も無くコンパイルされると思います． none.f90 PROGRAM Main INTEGER :: IXXXIX, I IXXXIX = 0 DO I = 1, 10 IXXXlX = IXXXIX + 1 END DO PRINT *, IXXXIX END PROGRAM コンパイルしたら実行してみましょう．どのような結果となるでしょうか？？？ none.f90 実行結果 0 「あれれれ？　10と表示されるはずでは？」と思った方は安心して下さい，極めて正常です．原因は分かりますか？　もうお気付きかと思いますが，ここで２行目にIMPLICIT NONEと入れて再度コンパイルしてみて下さい．そうですINTEGERの前の行です．さて結果は？ none.f90 修正版 PROGRAM Main IMPLICIT NONE INTEGER :: IXXXIX, I IXXXIX = 0 DO I = 1, 10 IXXXlX = IXXXIX + 1 END DO PRINT *, IXXXIX END PROGRAM 今度は下記のようなエラーが出ました． エラーメッセージの一例 cf90-113 f90fe: ERROR MAIN, File = none.f90, Line = 6, Column = 1 IMPLICIT NONE is specified in the local scope, therefore an explicit type must be specified for data object "IXXXLX". エラーメッセージは「６行目にエラーあり．IMPLICIT NONEが宣言されているので，IXXXLXという変数は明示的に宣言されなければならない．」と言っています．あれ，そんなIXXXLXなんていう変数を見た覚えは無いぞ，と思いきや実は６行目の左辺はIXXXIXではなく，「IXXXLX」（実際には小文字のL）とタイプミスが含まれているのでした… 　非常に簡単な例でしたが，これは暗黙の型宣言の弊害をよく説明しています．この種のバグは実に頻繁に入り，しかも駆除に困難を極め，時間を浪費してしまいます．問題はエラーメッセージも表示されず，（結果はおかしいが）ちゃんと動いてしまう点にあります．このような事態を未然に防ぐことができるのであれば，やらない手はありません． ■ IMPLICIT NONE とは？ 　IMPLICIT NONEは「暗黙の型宣言を使用しません」という宣言文です．これをプログラム単位の先頭部分に入れることによって，暗黙の型宣言が一切認められなくなります．つまり，明示的に型宣言されていない変数が存在する場合にはエラーとなります．ですから例のように，タイプミスを含む変数名が現れたとたんにコンパイラがきちんと教えてくれるのです． 　反面，変数を全ていちいち宣言してやらねばならない，ということになりますので「面倒臭い」という声が聞こえてきそうです．しかし，これだけの労力（大したことは無いと思いますが…）で問題を避けられるのならば是非にやってみるべきです！

【具体的な方法】

各プログラム単位の先頭にIMPLICIT NONEを置く

STEP 3 名前改善のススメ

名が体を表す変数名を！

【F77ユーザーへ】

※F77における「英字名」という用語は廃止され，F90から「名前 (name)」となりました．

【このSTEPのポイント】

分かりやすい変数名をつける

【期待される効果】

コードが見やすくなる 　　● 変数名からその役割がすぐに理解できる！

■ 未来の自分は他人 　F77では変数名については「６文字以内の英数字で，最初の文字が英字であるもの」という英字名に関する規則が適用されていました．このためプログラマは，苦労に苦労を重ねて少しでも分かりやすい名前を付けようと努力したものでした．例えば，空孔体積率という量を意味する変数を宣言する際に，英語で言うところのVoid Volume Fractionという長い名前を６文字で表現するというとんでもない作業が必要になり「VOIFRA」などという命名を余儀なくされるのです．他にも NOFELM, NODNUM……これらの変数が一体何を意味しているのか名前からすぐに分かりますか，読み取れますか？　はっきり言って不可能です．これらは書いた本人にしか分からないでしょう． 　変数表を見れば良いのですが，どこに行ったかわからなくなっていたり，そもそも存在しなかったりします．また，存在していても永年の変更に伴い，既に内容が大幅に変わっていたりもします．実際，コードを書いた本人も忘れてしまっていたりします（著者も経験あり）．これらを防ぐためのより現実的な方法は無いものでしょうか？　実際に動いているコードの中の変数自身に「君は一体なんなの？」と聞くのが一番確実なのですが，超能力でも無い限り無理です． 　コードの変更を行う際に，変数の持つ意味をきちんと理解していないととんでもないことになるケースが非常に多く，このような原因でバグが入るというのは非常に情けないことです．また，変数の意味を理解するという作業に時間をとられること自体もコーディングの効率を下げる要因となってしまいます．なんとかコードを見ただけで正確に意味を理解するための工夫ができないものでしょうか？ 　変数の意味を説明するコメントを変数宣言文の後ろに入れておくのは有力な手段です．しかしこれも変数表と同じく，コードの変更に伴ってマメにメンテしないと嘘つきコメントになってしまいますし，やはりコードの流れを追っていく最中に「この変数は何を意味してるんだっけ？」と宣言文に戻って一々コメントをチェックするのは，効率の面で良いとは言えません． ■ とにかく分かりやすさを追求 　F90から名前の長さが最大31文字に変更となりました．これにより意味の分かりやすい名前を変数に与えることができます．すなわち先の例では，Void_Volume_Fractionと用語をそのまま変数名とすることができます．これが一番の解決策で，変数自身がその意味を教えてくれます．「変数名が長くなるとタイプミスが入る可能性が高くなる」という指摘が聞こえてきそうですが，コピペという便利な機能を駆使すれば何の問題もありませんね．すなわち，変数宣言文を書く時だけタイプし，実行文中には全てコピペという方針が良いかも知れません．IMPLICIT NONEとの併用でより強固なコードとなります． 　この規則を存分に利用して，名が体を表す変数名を付けるようにしましょう！

【具体的な方法】

宣言文における変数名を分かりやすいものに変更，あとはコピペで修正！

STEP 4 END DOのススメ

ループはコンパクトにまとめよう！

【このSTEPのポイント】

END DOを使う

【期待される効果】

コードが見やすくなる 　　● 実行速度の改善（最適化）に寄与する場合もある 　コードが書きやすくなる 　　● 文番号の重複を考える必要が無くなる 　　　　↑ そもそも文番号を使う必要がない，コピペに強い！

■ プログラムの流れを明快に ■ コード変更に強くする

【具体的な方法】

END DOでループを閉じ，CONTINUE文を使わないようにする

STEP 5 COMMON「廃止」のススメ

大域変数の扱いをスマートに

【このSTEPのポイント】

MODULE & USEを使う

【期待される効果】

コード変更に強くなる 　　● 大域変数の追加が容易 　バグの削減 　　● ONLY句の併用で大域変数の誤用を防ぐ

■ COMMONの弊害 ■ INCLUDEではダメか？ ■やっぱりMODULEとUSEで

【具体的な方法】

INTENTで仮引数の属性を縛る

STEP 6 INTENTのススメ

副プログラム更新時におけるバグの侵入を防ぐ

【このSTEPのポイント】

INTENTを使う

【期待される効果】

コードが見やすくなる 　　● 仮引数の働きを明示する 　バグの削減 　　● 副プログラム処理における実引数の破壊を防ぐ

■ 思った結果が得られない ■ コード変更に強くする

【具体的な方法】

INTENTで仮引数の属性を縛る

最後に

上記のステップを踏むことによるわずかな労力で，F95への移行とコード改善とが同時に実現されます．これによって更なるF95学習のきっかけとなれば言うことありません．ぜひご検討いただき，お試しください．