導入
PL/Iでソースコードを記述する際、DCLやBINといった短縮形を目にする機会は多いはずです。これらはタイピングの手間を省くための機能ですが、チーム開発においては「保守性」とのトレードオフになります。本稿では、短縮形を実務でどのように扱い、どのような点に注意すべきかを解説します。
基礎知識
PL/Iには、言語仕様として定義された「短縮形（Abbreviations）」が存在します。例えば、DECLAREをDCL、CHARACTERをCHAR、VARYINGをVARと記述しても、コンパイラは完全に同一のコードとして解釈します。これは、メモリが貴重だったメインフレーム黎明期の名残とも言えますが、現代の環境でもコードの可読性を高める手段として活用されています。
実装/解決策
実務における短縮形の運用で最も重要なのは、「プロジェクト内でのコーディング規約の統一」です。
例えば、属性宣言において「BINARY」と記述するのか「BIN」とするのか、あるいは「FIXED BIN(31)」とするのか。これらを開発者間で統一しないと、ソースコードの見た目がバラバラになり、コードレビューや修正作業の効率を著しく低下させます。
サンプルプログラム
以下に、属性宣言において短縮形を適用した標準的な記述例を示します。
/ サンプルコード：属性宣言の短縮形活用 /
/ 規約により、頻出する型定義には短縮形を使用する例 /
/ 固定小数点数と可変長文字列の宣言 /
DCL COUNTER FIXED BIN(31) INIT(0); / BINARYの短縮形 /
DCL MSG_TEXT CHAR(100) VAR; / CHARACTERとVARYINGの短縮形 /
/ ポインタとアドレス演算の例 /
DCL P PTR; / POINTERの短縮形 /
DCL VAL FIXED BIN(31) BASED(P); / BASED属性の併用 /
/ 処理開始 /
COUNTER = 10;
MSG_TEXT = ‘処理が完了しました’;
/ ※注意: コードの先頭でどの短縮形を採用するかを決めておくと、後の解析が容易になります /
応用・注意点
短縮形を運用する上で最も注意すべきは、プログラムの解析や保守ツールへの影響です。
特に、自作の解析ツールや移行支援ツールを運用している場合、`FIXED BIN`, `BIN`, `F BIN` といった揺らぎを許容してしまうと、パーサーが正しく情報を抽出できません。
現場でツールを開発・導入する際は、以下の点を確認してください。
1. 正規化処理の導入: 解析の第一段階で、キーワードを正式名称（DECLARE, BINARYなど）に置換する正規化ロジックを組み込むこと。
2. 辞書設定の網羅: ツール側の辞書に、公式に認められた短縮形のバリエーションを漏れなく登録しておくこと。
短縮形は便利なツールですが、あくまで「読みやすさ」を損なわない範囲で、チーム内でルールを決めて運用することが、中長期的なメインフレーム開発の品質維持につながります。
コメント