ブライアン・マイヤーズ著

なつかしのコメディ劇「2000歳の男（The 2,000 Year-Old Man）」では真面目なカール・ライナーが、古代からやってきたところを発見されたばかりの、ニューヨークのイディッシュ語訛りで話すメル・ブルックスにインタビューしています。ブルックスが自分の記憶をライナーに話すにつれて、過去2000年の間の変わりようと成功に驚愕し（「人類最大の成功はサランラップだ」）、長生きの秘訣を披露しています（「バスに駆け込み乗車したことは一度もない」）。

昔のRPGプログラマが今日のRPGプログラムを見ると、2000歳の男と同じような不安な畏怖を感じるかもしれません。最新のリリースではRPG言語に多数の変更がなされていて、RPG IVをコーディングしている人でも最新の機能を活用するにはリフレッシュ・コースを受講する必要があるかもしれません。現在のRGP IVプログラムは1960年代に陸地に這い上がってきたオリジナルのRPGとはおよそ似ても似つかぬものになっているからです。

言語が変化していくのと同じくらいの速さで、その言語を使用したベスト・プラクティスやスタイル・ガイドラインも変化しつづけることがわかってきました。標準や実践例について語る場合の目標はアプリケーション開発プロセスを加速することであり、プログラムの保守を容易にすることであり、エラーを減少させることであるべきです。こうした目標は、コードの再利用や標準を常に念頭においてプログラムを記述することで達成できます。

本稿では、読みやすく、理解しやすく、しかも保守が容易なRPG IVプログラムを記述するための最新のアドバイスをご紹介します。ここでご紹介するガイドラインのほとんどはV5R1を前提としています。それより新しいリリースが必要なアドバイスについてはその要件を記述します。

フォーマット・フリーその2
私の言うことを復唱してください。「RPG IVはフリー・フォーマットの言語です。固定フォーマットの計算はもう使いません。」これがRPG IVスタイルに関する主な掟です。

フリー・フォーマットの利点は証明済みです。固定フォーマットのコードと比較するとコードが読みやすく、ドキュメント化しやすく、保守も容易です。また構文も、より新しい他のコンピュータ言語の構文との一貫性があります。

多くの場合、フリー・フォーマットの仕様を使用すると良い標準が生まれるのが自然です。というのは、新しい仕様により、固定フォーマットのC仕様では通用した古い考え方や粗末な実践例が通用しなくなるからです。またV5R2以降、RPGの新機能のほとんどがフリー・フォーマットでのみサポートされています。

C仕様では固定フォーマットとフリー・フォーマットの混用を避けてください。混用すると一貫性がなくなりコードが読みづらくなります。フリー・フォーマット仕様によるより自然な秩序と拡張されたスペースを大いに利用してください。ループやグループをコーディングするときは、フリー・フォーマットで記述した方がコードがきれいに見えるでしょう。算術式、文字列、論理式、代入と比較、（必要な場合は）添え字のセットなど、可能な場合はできる限りフリー・フォーマットを使用してください。しかし列の整列機能は式を読みやすくするツールですので、使用を完全に止めることはしないでください。特に式が次の行に続くときは式を整列して理解しやすくしてください。

/Free
　　TotalPay = (RegHours * Rate)　　　+
　　　　　　　　　　(OvtHours * Rate * 1.5) +
　　　　　　　　　　(DblHours * Rate * 2);
/End-free

残念ながら、埋め込みSQL文では固定フォーマットのエントリが必要です。この著しい設計上の失敗をIBMが改めるまでの間は、図1に示すようにSQLとマッチするようにRPGコードをインデントすることで、目障りなコードをいくらか見やすくすることができます。

ILEの採用
PRG IVスタイルの2番目の戒めは「RPG IVとILEは表裏一体となって結合されているので決してバラバラにしてはいけない」というものです。

RPGプログラマ（もっとひどい場合はマネージャやコンサルタント）が「RPG IVを使っていますが、バインディング関係には手を出さないんです」と私に言ってくると、私はいつも静かに不満を表します。RPG IVの構文は統合言語環境（ILE: Integrated Language Environment）と組み合わされて、アプリケーション・プログラミングに対するモジュール化アプローチを促進するものです。モジュール性はアプリケーションを整理し、プログラムの保守を容易にし、複雑なロジックを隠蔽し、適用可能な場合はいつでもコードの再利用を効率的に進めるための手段を提供します。

プロシージャ中の再利用可能なコードを独立させてください。融通の利かない万能の怪物ではなく、もっと小さくて単機能のコンパイル単位を記述し、必要とするプログラムになるようにバインドしてください。コードの重複はほんのわずかであっても避けましょう。コーディングの信条は「一度だけ書く」でなくてはなりません。

不可解なコードはやめて、分かりやすい名前のプロシージャを書いてきちんとドキュメント化してください。いくら努力したとしても、非常に稀な場合を除いて、コメントを一切付けずにコードの塊の意味をわかりやすくすることはできません。きちんとドキュメント化されて十分にテストもされているコードをプロシージャとして分離することで、保守プログラマがコードを必要以上に解読したり格闘したりするというトラブルに陥らないようにすることができます。

バインディング辞書を一貫して使用してください。バインディング辞書はプログラムを作成するのに必要な「コード片」を整理するのに役立つオブジェクトです。バインディング辞書を使用して頻繁に使用するモジュールやサービス・プログラムを一覧にしておくと、プログラムとCRTPGM（Create Program）コマンドやCRTSRVPGM（Create Service Program）コマンドとをバインドする際に必要なコンポーネントを明示的に一覧させる代わりにバインディング辞書を参照できるので、作業が単調でなくなりエラーも防ぐことができます。バインディング辞書を効率的に使用するには、バインディング辞書に対して一貫した使い方をしなければなりません。おそらく最も有用な使い方は、複数アプリケーションに渡って再利用可能なコードを参照している汎用のバインディング辞書と、一つのアプリケーションだけに関係するコード用のアプリケーション固有なバインディング辞書を合わせて持つ、という方法でしょう。

頻繁に再利用するプロシージャはサービス・プログラムにパッケージ化してください。サービス・プログラムは、プロシージャを必要とする各プログラムにそのコードを物理的にコピーすることなく再利用できるようにするためのエレガントな方法です。一般的なルールとして、あるプロシージャが二つ以上のプログラムで使われるのであれば、そのプロシージャをパッケージ化してサービス・プログラムとするべきでしょう。

バインダー言語を使用してサービス・プログラムの署名をコントロールしてください。CRTSRVPGMコマンドでEXPORT（*ALL）を指定して、バインダーにサービス・プログラムの署名を処理させたくなります。しかしこのようなやり方は結局は保守のときに悪夢を見ることになります。バインダー言語ソースを使用するとサービス・プログラムの署名を明示的にコントロールでき、そしてさらに重要なことですが、サービス・プログラムが複数の署名を持てるようにできます。つまりこの機能によって、そのサービス・プログラムを使用するプログラムには一切手を加えることなく、サービス・プログラムへ大きな変更（プロシージャの追加、変更、削除）を加えられるということになります。

RPG IVのプロトタイピング機能を使用してパラメータやプロシージャのインタフェースを定義してください。プロトタイプ（PR定義）やプロシージャ・インタフェース（PI定義）を使用すると、モジュール間やプログラム間でデータをやり取りする際に役立つ点が多数あります。たとえば、データ・タイプやパラメータ数をコンパイラにチェックさせることで、実行時のエラーを回避することができます。またプロトタイプを使用すると、リテラルや式をD仕様中でパラメータ・リスト（*ENTRY PLISTも含む）としてコーディングでき、パラメータを参照渡しだけでなく、値渡し、読み取り専用参照渡しなどで渡すことができます。

プロトタイプは/COPYメンバーに格納してください。各モジュールに対して/COPYメンバーをコーディングし、その中にそのモジュール中にエキスポートされたプロシージャのプロシージャ・プロトタイプをコーディングします。そして、呼び出されたモジュール中のプロシージャを参照している各モジュールに、前述の/COPYモジュールへの参照を含めます。こうすることで、プロトタイプを必要とするときに毎回そのプロトタイプを入力する手間が省け、エラーも低減できます。小さなサイズの/COPYメンバーをたくさん持つ代わりに、再利用可能なプロシージャのすべてまたはほとんどに対するプロトタイプを含むマスターの/COPYメンバーを作るという方法もあります。

RPGの条件付きコンパイル・ディレクティブを使用することを検討するのも良いでしょう。条件付きコンパイル・ディレクティブでは、どこでも使える/COPYメンバーを使用する代わりに実際のプロシージャ・ソースのプロトタイプを使用することができます。このテクニックを使うと、使われないプロトタイプがコンパイル・プロセスにかけられることを防ぐことができます（使われないプロトタイプがコンパイル・プロセスにかけられても実行時のペナルティはありませんが）。

モジュールの定数宣言はそのモジュールのプロトタイプと同じ/COPYメンバー中に含めてください。こうしておいて呼び出されたモジュールを参照しているモジュール中の/COPYメンバーを参照すると、そこにある定数宣言を事実上「グローバル化した」ことになります。

IMPORTまたはEXPORTはグローバルなデータ項目に対してだけ使用してください。IMPORTキーワードとEXPORTキーワードを使用すると、プログラム中のプロシージャ間でデータを明示的にパラメータとして渡さずに共有することができます。別の言い方をすると、プロシージャ間の「隠れたインタフェース」を提供していることになります。上記のキーワードを使用するのはプログラム中で本当にグローバルなデータ項目、通常は一度だけ設定されて二度と変更されない値だけにしてください。

宣言の集中化
RPG IVでは、プログラムに関連したすべての変数や定数を宣言するためのプログラム中のエリアがようやくできました。D仕様を使用して宣言をすべて一箇所に整理してください。D仕様内では以下のような定義タイプ別に分かりやすい順序で定義を整理します。

　　・ メイン・プロシージャのプロトタイプ
　　・ メイン・プロシージャのプロシージャ・インタフェース
　　・ その他のプロトタイプ定義
　　・ 名前付き定数
　　・ データ構造
　　・ 単独の変数

各定義タイプ中では宣言をアルファベット順に並べます。

リテラルを使用する代わりに、名前付き定数として宣言してください。こうするとコードをドキュメントしやすく、保守も容易になります。このルールの明らかな例外は、文のコンテキスト中で0と1が意味をなすのであれば使用しても構わないというものです。たとえば、アキュムレータ・フィールドを初期化したり、カウンタの値を一つ増やすときには0や1をソース・コード中にハード・コードしても構いません。

データ項目名をインデントして読みやすくし、データ構造をドキュメント化してください。定義された項目の名前は、他のRPGエントリとは違ってD仕様中で左寄せする必要はありません（図2）。この機能を利用してコードのドキュメント化をしてください。

コードを読みやすくするには7カラム目をいつも空白にしておいてください。（H仕様においても7カラム目を空白にするという同じルールが当てはまります。）

データ構造の定義では位置記法ではなく長さ記法を使用してください。D仕様を使用すると特定の位置のフィールドかまたは単にフィールドの長さだけをコーディングすることができます。混同を避け、フィールドをうまくドキュメント化するためには、常に長さ記法を使用することです。たとえば、

D RtnCode　　　　DS
D PackedNbr　　　　　　　1　　　8P 5

ではなく

D RtnCode　　　　DS
D PackedNbr　　　　　　　　　　15P 5

のようにコーディングしてください。

位置記法はデータ構造中における実際の位置が重要である場合のみ使用してください。たとえば、プログラム・ステータスのデータ構造やファイル情報データ構造、APIからの戻り値データ構造をコーディングするときは、フィールドにつながるあるいはフィールド間の特定の位置をプログラムが無視した場合、位置記法を使用します。位置記法は、不要な「フィラー」変数と長さ記法を一緒に使用するよりは好ましいものです。ただし位置記法を用いた場合でも、図3に示すように、位置宣言をした変数を長さ記法で宣言した他の変数でオーバーレイして、変数を分かりやすくドキュメント化してください。

オーバーラップしたフィールドを定義するときは、位置記法ではなくOVERLAYキーワードを使用してください。OVERLAYキーワードを使用すると「子」変数の宣言と「親」変数の宣言を明示的に結び付けます。OVERLAYを使用するとこの親子関係がドキュメント化されるだけでなく、親変数がプログラム・コード中のどこかへ移動した場合も子変数がそれに付いていくことができます。

コンパイル時配列の使用は避けてください。プログラムを個々のプロシージャに分解する際、関係する全てのコード片を物理的にも論理的にも独立したものにしておくと便利です。今までのコンパイル時配列コーディングは、配列の定義と配列のデータがプログラム中でおそらく数千行も隔てて別々のところに記述されていました。データ構造の中に配列をコーディングするのがもっと良いソリューションです（図4）。

データ構造を複数箇所で記述しないようにしてください。V5R2の配列データ構造は、プログラム中で標準の配列記法を使用しており、一行の中に処理を一度しか記述できないという制限もなく、入れ子（多次元）配列が便利な場合にそのインスタンスを扱えるため、他のコンストラクトよりも便利です。

修飾（QUALIFIED）データ構造を使用してください。修飾データ構造を使用すると、データ構造のサブフィールド名をデータ構造名（Customer.Name、Cstomer.Address等）でチェックしなければなりません。これによってデータ項目の起源がわかるため、ドキュメント化するのに大変便利であるばかりでなく、異なるデータ構造中で同じ名前のフィールドを使用することができます（Before.Name、After.Name等）。修飾データ構造を定義するには、そのデータ構造の定義中でQUALIFIEDキーワードを使用します。

LIKEDSキーワードとLIKEREC（V5R2）キーワードも、データ構造が他のデータ構造やレコード形式からサブフィールドを「継承」するときに使用すると便利です。またV5R2では、*ALL、*INPUT、*OUPUT、*KEYフィールドを指定することで、LIKERECデータ構造や外部で記述されたデータ構造中のサブフィールドをコントロールすることもできます。

命名法の拡張
プログラミング・スタイルで最も重要な側面は、データ項目（変数や名前付き定数等）やルーチンに付ける名前の付け方でしょう。今までの6文字よりも長い名前の命名法を確立し、変数やその他の識別子を完全に識別できるようにしてください。文字数が増えたことでプログラムの「コード」とプログラムの「記述」との違いが出てきます。

項目に名前を付けるときはその項目を完全かつ正確に記述する名前にしてください。名前はあいまいさがなく、読みやすく、わかりやすいものでなければなりません。RPG IVで長い名前を使えるようになったことを利用すべきではありますが、長すぎて不便な名前を付けてはいけません。通常は10文字から14文字の長さがあれば十分で、それ以上の長さの名前は実用的ではないでしょう。

データ項目に名前を付けるときはその項目を説明するような名前にしてください。戻り値があるプロシージャに名前を付けるときは、戻り値がわかるような名前を付けるか、そのプロシージャがデータ値を取り出すものなのかデータ値を割り当てるものなのかによって「get/set」などを使用します。
戻り値のないサブルーチンやプロシージャについては、（CLコマンドと同様に）動詞／目的語の構文を用いてそのプロセスを記述します。名前、動詞、目的語の辞書を管理し、この辞書を使って命名法を標準化してください。

RPGシンボル名をコーディングするときは、大文字と小文字を組み合わせて、名前付きの項目の意味と使用法を明確にしてください。RPG IVではソース・コードを入力する際、大文字と小文字を使用することができます。この機能を利用して名前つきデータを明確にしましょう。RPGの予約語や操作については全て大文字を使用するようにしてください。

項目に名前を付けるときは、特殊文字（@、#、$等）の使用は避けてください。こうした特殊文字の中には文字セットによってはコンパイル・エラーを起こす可能性があります。RPG IVでは名前の中でアンダースコア（_）を使うことができますが、大文字と小文字を上手に組み合わせれば、簡単にこの「目障りな」文字を使わなくても済むようにできます。

インジケータのないコードを書く
RPGの歴史上、インジケータはRPG構文における目立った特徴でしたが、RPV IVでは一気に過去の遺物となってしまいました。プログラム中でインジケータの使用を減らすことが、プログラムの読みやすさを向上させるためにできる唯一最も重要なことかもしれません。

RPGのソース・コード中の数字つきインジケータをなくしてください。RPG IVでは条件付きインジケータとその結果生じるインジケータを使う必要が全くなくなり、フリー・フォーマットの仕様ではこれらのインジケータがサポートされていません。インジケータ・データ構造（INDDSキーワード）といくつかの組み込み関数（BIF）が登場したことで、予め定義された数字つきインジケータが過去のものになってしまいました。エラー処理BIF（%EOF、%ERROR、%FOUND等）とE操作エクステンダを使ってファイル例外を指定し、インジケータを使用しなくても済むようにすることができることを覚えておいてください。

インジケータを使用しなければならない場合は名前を付けてください。RPG IVはインジケータと同じ目的を果たすブール値データ・タイプ（N）をサポートしています。INDDSキーワードと表示ファイル仕様を一緒に使用して、データ構造と表示ファイルまたはプリンタ・ファイル用のインジケータを関連付けることができますので、インジケータに意味のある名前を付けることができます。

使用しているインジケータには全て説明を付けてください。数字つきインジケータを全てなくしたとしても、予め定義されたインジケータ（L0レベルからL9レベルのブレーク・インジケータやU1からU8の外部インジケータ等）がたくさん残っている場合があります。通常、プログラムを読んだだけではこうしたインジケータの意味がすぐにわかるわけではないので、インジケータについてのドキュメントを残すことが特に重要です。インジケータの一覧を序文に記述しておくと良いでしょう。

構造化プログラミングのテクニック
あなたが書いたプログラムを読もうとしている人に対して、構造化プログラミングのテクニックを常に実践してプログラムをわかりやすくしてあげてください。IF、DOU、DOW、WHENなどといったいわゆる「構造化」操作コードはフリー・フォーマットの式をサポートしており、今までの固定フォーマットのコードよりも読みやすくなっています。一般的に、操作コードにフリー・フォーマットの選択肢があればフリー・フォーマットを使用してください。このルールはDO操作コードにも当てはまります。通常はフリー・フォーマットのFOR操作を選択するのが良いでしょう。ところで、インジケータを使って条件構造化操作コードを書いたことなどありませんよね。それなら結構です。

GOTO、CABxx、COMPは使わないでください。その代わりに、入れ子になったIF文かステータス変数などの構造化選択肢で置き換えて、コードをスキップするか、プログラムを特定の位置に差し向けてください。ループを実行するにはDOU、DOW、FORを使用してください。COMP（IFも含む）やGOTOを使って比較や分岐してループをコーディングしてはいけません。ITERを使ってループの繰り返しを行い、LEAVEやLEAVESRをそれぞれループやサブルーチンのパラメータとして使ってループから脱出してください。

SELECT/ WHEN/OTHER/ENDSLを使ってマルチパスの比較を行ってください。何重にも入れ子になったIfxx/ELSE/ENDIFのコード・ブロックは読みづらく、グループの終わりのところでENDIFが不恰好に集まってしまいます。ELSEIFを使えば多少は良くなりますが、通常はSELECT/WHEN/OTHERを使う方がより良くしかも融通の利くコンストラクトです。使われなくなったCASxx操作コードについても同じアドバイスが成り立ちます。代わりにSELECT/WHEN/OTHERを使ってください。

文字列操作
IBMは、文字列を簡単に操作するためのRPG IVの機能を大幅に強化しました。今までのバージョンのRPGで使わなければならなかったいろいろなトリックはもう過去のものになりました。この新機能を活用してコードをモダンなものにしてください。

文字列定数を配列やテーブル中に格納せずに、名前つき定数を使用して文字列定数を定義してください。文字列は配列名と添え字を使って参照しなければならなかったのですが、その代わりに、文字列を（CLコマンド文字列のような）名前つき定数として宣言することにより、その文字列を直接参照することができます。名前つき定数を使用して、プログラムの実行中に変更されたくない任意の値を宣言します。

配列やデータ構造を使って文字列やテキストの操作をすることは避けてください。その代わりに、新しい文字列操作用操作コードやBIFを使ってください。

文字列操作をする際には、EVALのフリー・フォーマット割り当て式が使用可能であれば使用してください。EVALを文字列に対して使用すると、通常はMOVEL(P)操作コードを使用したのと同じことになります。結果を空白で埋めたくない場合は、%SUBST関数または%REPLACE関数を使用します。

可変長フィールドを使用して文字列処理を簡素化してください。作業フィールドだけでなく、あらゆる文字列処理サブ・プロシージャに対して可変長フィールドをCONSTパラメータまたはVALUEパラメータとして使用してください。コードが読みやすくなる（%TRIM関数がなくなる等）だけでなく、固定長フィールドを使用するよりも実行速度が速くなります。たとえば、図5bのようなコードではなく、図5aのようなコードを使用してください。

コマンドを賢く使う
良いプログラミング・スタイルというものは、ドキュメントとしての目的も提供し、第三者がコードを理解しやすくします。コードの構成テクニックを上手に実践していれば、ソース・コードにコメントする際には「余計なことは書かない」のが大切だとわかるでしょう。コメントが多過ぎるのはコメントが少なすぎるのと同じくらい悪いことです。コメントに関するガイドラインを以下に示します。

//コメントのみを使ってください。RPG IVでは、従来の7カラム目のアスタリスク（*）の代わりに2つのスラッシュ文字（//）で始まるコメントを使えるようになりました。フリー・フォーマットのコードではアスタリスクが使えないため、コメント行は8カラム目から80カラム目の間のどこからでも始めることができ、既存の実行可能な文と同じ行に書いても構いません。

この新しいコメント・フォームで、固定フォーマット仕様でのアスタリスクを使ったコメントを置き換えることができますが、コメントは一行に収まっていなければなりません。一貫性を保つため、固定フォーマットの仕様においても新しいフォームのみを使用してください（図6）。

コメントはコードを繰り返すのではなく、コードを明確にしてください。コードとそれを単に繰り返すだけのコメントはプログラムのサイズを増大させるだけで何の価値もありません。一般的に、コメントは以下の3つの目的だけに使用すべきです。

・ プログラムやプロシージャの簡単な要約を提供する。
・ サブルーチン、プロシージャやコードのその他の部分にタイトルを付ける。
・ ソース・コードを読んだだけではわからないテクニックを説明する

プログラムやプロシージャの冒頭の部分に、簡単な要約を必ず入れてください。この冒頭部分には以下の情報を含めてください。

・ プログラムまたはプロシージャのタイトル
・ プログラムやプロシージャの目的の簡単な説明
・ 変更日、変更したプログラマの名前、変更の目的などの履歴
・ インジケータの使用の要約
・ プロシージャ・インタフェース（戻り値とパラメータ）の説明
・ プロシージャの呼び出し方の例

一貫した「マーカー行」コメントを使用して、コードの主要な部分を分割してください。たとえば、宣言、メイン・プロシージャ、各サブルーチン、サブ・プロシージャの間はダッシュ（-）の行で必ず分けてください。それぞれの部分を参照しやすいようにしてください。

空白行を使って関連するソース・コード行をグループ化し、目立つようにしてください。一般的には、コメントの塊を記述しようとしているのではない限り、ソース・コードの行をグループ化するには空白のコメント行を使うのではなく、完全に空白の行を使用すべきです。ただし空行は一行だけにしてください。複数の空行を連続させるとプログラムが読みづらくなります。

81カラムから100カラム目での「行の終わり」の右端のコメントはしないでください。右端のコメントは単にコードを繰り返すことになりがちで、プログラムの保守中に失われることもあり、コメントの対象となっている行と簡単に「合致しない」ことになります。特に、コードの中にコメントを書けるようになったので、右端のコメントは使用しないでください。

陳腐化した機能を避ける
RPGは古い言語です。40年を経た今でも、陳腐化したオリジナルの機能を使うことが可能です。しかし、そのような古い機能は使わないでください。

旧式の操作コードをなくしてください。どの操作コードが旧式の操作コードであるかわかりますか。答えは簡単です。フリー・フォーマットがそれをサポートしていなければ、その操作コードは旧式です。フリー・フォーマットの仕様を導入するに際し、IBMはこの機会を利用してサポートする操作コードの数を約半分の60個にしてRPGを簡素化しました。今後使用すべきではない操作コードに代わる望ましいコードの一覧を図7に示しました。

ある関数がある操作コードと同じ機能を提供するものであれば、操作コードではなくその関数を使用してください。操作コードの一部については、BIFで置き換えることが可能で、式中で関数を使うことができます。操作コードと同じ機能を持った関数があればその関数を使うほうが望ましいです。

プログラム記述ファイルは使用しないでください。代わりに、可能なときは必ず外部定義ファイルを使用してください。

ネイティブ日付データ・タイプを使用して日付の処理をしてください。長年にわたって収集し、一所懸命守ってきた日付および時間に関するルーチンを排除してください。RPG IVの日付関連のBIFの方がもっと効率的でわかりやすくモダンです。データベース中に「レガシーの」フォーマットの日付があったとしても、日付関数（%DATE、%DIFF、%SUBDT、%DAYS等）を使って処理することができます。

１から5カラム目のプログラム行番号で順番を付けないでください。もはやパンチ・カードの束を床に落とすようなことはないので、プログラムの順番エリアは不要です。RPG IVでは1から5カラム目はコメントのみに使用します。このカラムはプログラムの変更された行や構造化されたインデント・レベルを識別するのに使用しても構いませんが、右端のコメントと同様の危険をはらんでいることに注意してください。

その他のガイドライン
RPG IVのコードを改良するのに役立つその他のスタイル・ガイドライン集を以下に示します。

プログラミング上のトリックは使わないでください。そうした操作はトリックを知らない人にとっては大して効果のあるものではありません。コード・ブロックがどのように動作するのかを説明するコメントを追加する必要があると思われる場合は、そのコードの目的が明確になるように書き替えるか、コードの複雑さをプロシージャの中に隠蔽してしまうことを検討してみてください。わかりづらい「ビット操作」操作コード（BITON、BITOFF、MxxZO、TESTB、TESTZ）を使っているということは、ソース・コードを見直す必要があるという兆候かもしれません。

キーワードをサポートしている仕様では、キーワードは常に一行に一個までに制限してください。仕様全体に渡って複数のキーワードや値をあちこちで使用する代わりに、キーワードは一行に一個までにするか、少なくとも密接に関連しているキーワード（DATFMT、TIMFMT等）に制限すれば、プログラムが読みやすくなり仕様の追加や削除が容易になります。

H仕様のキーワードは8カラム目から始め、7カラム目は空白にしておいてください。キーワードと、6カラム目に必要なHとを分けることでプログラムが読みやすくなります。

最後のアドバイス
良いスタイルを守ったとしても、かならずしも実行時のパフォーマンス向上につながるとは限りません。スタイルとパフォーマンスが対立したときは、常に良いスタイルを守るようにしてください。読みにくいプログラムはデバッグするのも難しく、保守も困難で、正しいプログラムにすることが難しいものです。正しいプログラムを書くことは常にスピードよりも優先されます。ブライアン・カーニハン氏とP.J.プラウガー氏が書いた「The Elements of Programming Style （McGraw-Hill; 2nd edition, 1978）」にある忠告を心にとめておいてください。

　　・ 速くするよりは正しくする。
　　・ もっと速いコードにしようとするときは正しい方法で行う。
　　・ 速いコードにする前にわかりやすいコードにする。
　　・ 実行効率を少しばかり向上させるためにわかりやすさを犠牲にしない。

ブライアン・マイヤーズ はベル・データ�鰍ﾌ業務提携先である米国Penton Media, Incが発行しているiSeries NEWSのテクニカル・エディターで、RPG IV Jump StartやProgramming in RPG IV （共に29th St. Press出版）等の著作もあります。同氏はiSeriesのさまざまなトピックについて、オンサイト、DVD、iSeries Networkのe-ラーニング・プログラムで講座を開いています。