こんなRPGを書いてはいけないその(1)

これまでこのサイトではTips & Techniquesとして良い例ばかりを
紹介してきたがある大手特約店のプログラマーが書いたRPG IIIプログラムを
解析する機会があったのだがわずか450ステップくらいのRPG IIIであったが
あまりにも間違いが多くて第三者が理解しにくく
また改良するに適していない書き方であり
そもそもがRPG命令を正しく理解していないのではと思えるような
コーディングであった。
実際のコーディングを紹介するわけにいかないので

かなりRPG命令を誤解しているようなので注意勧告として
このような記述をしてはいけない例を紹介していきたいと思う。

この最初の投稿ですべての誤りの例を紹介したかったのだが
あまりにも誤りが多いというか誤解が多いので
すべてを一度には書ききれないほどである。

■ 誤解その(1) 特殊文字の多用。￥マークは絶対使用してはならない

特殊文字￥, #, @　を意味なく多用することによって
トラブルを誘発するプログラムとなる。
￥は $ と同じで通貨記号でありCCSIDの影響を受けやすく
PCなどとの互換性がないので今の時代では絶対に使うべきではない文字である。
　別のCCSIDのソースでコンパイルするとコンパイル・エラーになることもある。
これらの文字を使うとダウンロードしたりPCオーガナイザー(STRPCCMD)で
不要なトラブルに見舞われることになる。
プロは￥などは絶対に使わない。
RPGの経験の少ない人ほどやたら意味もなく特殊文字を使いたがる。
その結果自分でトラブルを誘発することになる。

■ 誤解その(2) やたらに新しいフィールド名を定義する

　開発経験の少ない人ほどやたら新しいフィールドをたくさん定義する傾向にある。
しかも命名が連続番号であったりと覚えにくいフィールド名であったりする。
そのようにできたプログラムを解析しようとするとどのフィールド値が
どのフィールドに移されているのかを丹念に時間をかけて
追い続けていくしかない。
意味がわかるフィールド名にしておけば読み手はすぐに意味を判断することが
できるがこのようにフィールド定義を多用しているとやさしいプログラムを
意図的に難しくしてしまっているように見える。
バグを誘発するようにどうすればトラブルが多くなるかと考え抜かれて
作られているように見える。

[例] フィールド名 : PFZEA, PFKNA …. このような命名ではフィールドの意味は全く不明である。
URIKIN, SHZEI …. このようなフィールド名であれば内容を推測しやすい

■ 誤解その(3) フィールド内の値を理解していない

誤解その(2)でフィールド名の定義が多くなる原因のひとつはプログラマーが
フィールドの意味を正しく理解していないからでもある。

[誤った例]

  C                   Z-ADD     URTKCD        BK@TRA      
  C     BK@TRA        CHAIN     TOKMAS                             98
  C     *IN98         IFEQ      *OFF                                 
  C                   MOVEL(P)  TONAM         PNAME                  
  C                   ELSE                                           
  C                   MOVE      *BLANK        PNAME                  
  C                   ENDIF

[正しい例]

 C                   MOVE      *BLANKS       TONAM                  
 C     URTKCD        CHAIN     TOKMAS                             98
 C                   MOVEL(P)  TONAM         PNAME

[解説]

どこが誤りでまずいのかおわかりだろうか?
まず第一に得意先マスター: TOKMAS にCHAINをかけるのに
データの得意先コード: URTKCDを別のフィールド : BK@TRAに移してから
その BK@TRAを使ってCHAINをかけていることでこれは全く無意味である。
プログラマーは自信なく別のフィールドに移す必要があるのと
勘違いしているようだが直接 URTKCDでCHAINすべきである。

次にCHAINが成功したときと失敗したときとで別々のコーディングを
していることもよくない。
プログラムとできるだけ場合分けは少なくしてひとつの書式で
コーディングすべきである。
つまりできるだけ一般化するという考えがなくてはならない。
場合分けをおおくすると

・バグの発生可能性のある個所が多くなる
・保守すべき箇所が多くなる

のデメリットを生む。できるだけ条件分岐を少なくしたプログラムにすべきなのである。
正しい方の例を見てみると
事前に得意先名を

 C                   MOVE      *BLANKS       TONAM

でブランクにセットしておいて

 C     URTKCD        CHAIN     TOKMAS                             98
 C                   MOVEL(P)  TONAM         PNAME

としているのでCHAINが成功したときは TONAMには正しい得意先名が入り
CHAINが失敗したときは TONAM はブランクのままであるので
PNAMEにはブランクが入ることになる。
このようにステップは短くなって無用な条件や標識の必要がない。
これはCHAINの結果でフィールド値がどのように変わるのかを正しく理解しているから
このような一般化された短いコーディングができるのであって
理解がない場合は冗長なコーデングとなってしまう。

■ 誤解その(1) 特殊文字の多用。￥ マークは絶対使用してはならない