導入：なぜ「カッコ」の書き方にこだわるのか
COBOLの実務において、多次元配列（テーブル）の参照は避けて通れない処理です。特に`WS-TBL(I, J)`といった記述は日常的に行われますが、実はこの「カッコ」の周囲やカンマの後の空白ルールは、保守性とコンパイラの安定性に直結する重要なポイントです。コードの可読性を高めるだけでなく、特定の環境下で発生しうるパースエラーを未然に防ぐための、プロとしての作法を解説します。
基礎知識：添字とカッコの構造
COBOLの添字（Subscript）は、配列の要素を特定するための指標です。多次元配列の場合、添字はカンマで区切られます。
ここで重要なのは、COBOLは元来「空白」をトークンの区切りとして扱う言語であるという点です。しかし、添字のカッコ内に関しては、コンパイラの仕様やベンダーによって「空白を許容する範囲」が微妙に異なります。古いホスト系コンパイラからオープン系の最新環境へ移行する際、この記述の揺れが思わぬコンパイルエラーを招くケースが少なくありません。
実装・解決策：標準的な記述ルール
現場で最もトラブルが少なく、かつ可読性が高いとされる記述ルールは、「カンマの直後には半角スペースを入れ、カッコの直後には入れない」というスタイルです。
例：`WS-TBL(IDX-A, IDX-B)`
このように記述することで、人間には「配列の指定である」ことが明確に伝わり、かつ多くのコンパイラで字句解析上の曖昧さを排除できます。
サンプルプログラム
以下に、安全で実用的な多次元配列の参照コード例を記載します。
01 WS-AREA.
05 WS-TBL-ENTRY OCCURS 10 TIMES INDEXED BY I.
10 WS-SUB-TBL OCCURS 5 TIMES INDEXED BY J.
15 WS-VALUE PIC S9(04) COMP.
PROCEDURE DIVISION.
> 添字のカッコ内は、カンマの後にスペースを1つ置くのが最も安全な慣習です
> カッコ直後のスペースは誤解を招くため避けるべきです
MOVE 100 TO WS-TBL-ENTRY(I, J)
> 読み取り時の記述例
IF WS-TBL-ENTRY(I, J) > 0
DISPLAY “データあり: ” WS-TBL-ENTRY(I, J)
END-IF.
応用・注意点：現場で陥りやすい罠
1. カッコ直後の空白：`WS-TBL( I, J )`のように、開きカッコの直後にスペースを入れるスタイルを好む方もいますが、一部の古いコンパイラやプリコンパイラ（埋め込みSQLなど）では、これを「配列の開始」と正しく認識できず、構文エラーとなるケースがあります。原則として、開きカッコの直後には空白を入れないことが鉄則です。
2. インデックスと添字の混同：`INDEXED BY`で定義したインデックスを直接使う場合と、数値項目を添字として使う場合で、コンパイラがチェックする厳格さが異なることがあります。特に他言語から移行したメンバーがいるチームでは、記述の揺れを「コーディング規約」で統一しておくことが、属人化を防ぐ唯一の手段です。
3. 移植性の担保：メインフレームからオープン系へソースを移植する場合、ベンダーごとに「カッコ内の空白」に対する寛容さが異なります。迷ったときは、最も保守的なルール（カッコ直後は詰め、カンマの後はスペース1つ）に統一することで、環境依存のバグを最小限に抑えることができます。
コメント