【COBOL 読み3-9-1】読めるコメントを書く〜コメントから始まる瓶文通生活

🧩今日の学び
・COBOLのコメントは*>を使い、旧式コメントや行末コメントは避けるのが実務の基本
・コメントは処理内容ではなく「なぜそう書いたか」という判断理由を書くためのもの
CONTINUEIFの前後にコメントを添えることで、設計意図が未来へ確実に伝わる

なるお)係長ー、コメントの書き方ちゃんと教えてくださいよー。

係長)なんだよ、いまさら。

そもそもお前コメントぐらい書けるだろ。

な)書けるだろじゃなくって、教えてくださいよー。係長の見様見真似なんすから。

係長が嘘言ってたり、そもそも致命的間違いをしてたら、恥かくのは係長すよ!

係)なんで俺なんだよ…

な)うちの係長はほんとこうなんすよー、ほんと困ったもんですよー、って会話の切り出しに使うから?

係)使うなよ!

な)そして、怒りっぽいんだから、たまったもんじゃないんですよねーって続けられるから?

係)なんで続けるんだよ!

な)おたくも困ってますよねー、すみませんねー、いきなり怒鳴りだすから。ねーほんとそうですよねー

って話題が尽きなくて、俺がいい人になりますし、ね!大事でしょ!師匠ー!コメント教えて下さいよー。

係)だから続けるなよ!俺の悪口言いたいだけだろうが!何が師匠だ!

はぁ、もう、わかったよ…そもそもCOBOLの本買って読めば済む話じゃねーのか…

な)係長の口から聞きたいんすよー。

だって本は腹にたまらないんすよ!

紙は食えると思いますけど…。

でもでも、良い紙はツルツルにするためになんか処理が施されてそうで、添加物が怖いですし…。

係)そもそもなんで食うことが前提なんだよ…。

ったく、コメントの書き方は、COBOLで一番“性格が出る”ところだからな。
ちゃんと覚えておけよ。

な)らじゃこん!

COBOLのコメントは2系統

係) COBOLのコメントは「2系統」ある。

● フルラインコメント(基本)

*> ここはコメント
  • *>で始まる行は、完全なコメント
  • 今の主流(Enterprise COBOL / OpenCOBOL / GnuCOBOL)
  • これが正解ルート

基本的には、これ使えば良い。

*> どこでも書ける
PROCEDURE DIVISION.
*> インデントも自由

*> つまり
*> 左端から書いてもOK
       *> ネストに合わせてインデントしてもOK
    MOVE 10 TO A.  *> 命令の後ろ(行末)に書いてもOKだ。

● 旧式コメント(知識として)

* ここはコメント
  • 行頭1桁目に *
  • カード時代の名残
  • 今でも動くが、混在させると地獄

読めるけど 新規では使わないってことだ。

つまりはこういう形になるってことだ。

000100* ここしかコメント書けない
000200 PROCEDURE DIVISION.

旧式コメントはインデントもだめだぞ。きっとお前ならやるだろうが。

000100*←ここ(7桁目)にしか書けない。不自由。
000200     *←こうやってインデントするとエラーだ

な)信頼されてる!?

係)なんでだよ…

*> コメントの作法:スペース・位置・行末NGの理由

な)係長?*>のあとってスペース絶対です?

係)ちゃんと見てるな。そういう質問もいいぞ。

 *>の直後にスペースは「必須ではない」、実務的には「必ず入れる」が正解だ。

な)入れなくてもいいなら、入れないほうが楽ですよねー。何回スペース入れるんだって話で。

係)読みづらいだろ。

な)え?それだけ?

係)お前な、見づらいコメント見たいかって話だぞ。

*>コメント
*>これは初期化処理

*> コメント
*> これは初期化処理

まぁそれだけではないがな。他には以下のような理由がある。

ツール・整形・差分で事故りにくい

  • フォーマッタ
  • 差分ツール
  • エディタのコメント判定

チーム・レビュー文化

レビューでよく言われるのが「コメントは文章なんだから、記号のあとに空白入れよう」ということだ。

COBOL に限らず、ほぼ全言語で同じ文化だ。

とはいえ、可読性を第一に考えろ。

な)きた!いつもの可読性!

係)何喜んでんだよ…。

で、行末コメントは「原則NG」と思っておけ。

MOVE A TO B *> AをBにコピー

書ける処理系もあるが、

  • 差分が見づらい
  • 折り返しで壊れる
  • レガシー環境で死ぬ

COBOLではやらない文化だ。

良いコメントとは何か:処理ではなく判断を書く

係)例えばだ、こんなコメントは俺は書かない。

*> AをBに代入する
MOVE A TO B

見て分かることを書いてコードをごちゃごちゃさせたくないからな。

そうじゃなくて、理由・背景・前提を書け。

*> 初期値は前回バッチの結果を引き継ぐ
MOVE A TO B

コードは何をしているか、コメントはなぜそうしているか、これが鉄則だ。

あとIFCONTINUEと相性がいい書き方としては、

*> OK時はあえて何もしない(将来拡張前提)
IF STATUS = "OK"
    CONTINUE
ELSE
    DISPLAY "エラー"
END-IF

CONTINUE単体でも意図は伝わるが、コメントがあると 「設計判断」だと確定する

つまり、コメントは「未来の自分たちへの手紙」ということだぞ。

それは自分に向けてにならないかもしれんが、次のやつに理解されて行けば、気持ちが繋がっていくってもんだ。

な)さすが係長!

係)お、なんか素直に感嘆されると照れるな…。

な)海に瓶投げて文通しようとしてたタイプですね!

係)は?

な)いやー係長はそういう純情純真ピュアラブロマンスタイプだと思ってましたよー。

顔に似合わず少女漫画好きですもんね!

住所は書いてたんすよね!返事は来たんすか!?

係)なんで鼻息荒くなってんだよ…

いいからまとめるぞ!

*>を使え

・行末コメントは避けろ

・処理の説明を書くな、判断の理由を書け

CONTINUE・EXIT・CALL の前後こそコメントの出番

これ守ってりゃ「読めるCOBOL書く人」 って言われるようになるぞ。

おむすび

な)おー!かっこいい!俺にお似合いのキャッチコピーですね!

係)どこがだよ!

な)でも、確かにこうやって残しておくと、

*> 今日も老害まっしぐらでした!
IF STATUS = "OK"
    CONTINUE
ELSE
    DISPLAY "エラー"
END-IF

係長の行動記録がわかりますね!

係)お前はどうしても俺を陥れたいんだな…

な)いやだなー愛ですよ愛!

業務連絡も瓶でやり取りしましょ!海に投げてください!

係)届くかよ!

な)そこがいいんじゃないですかー。届かないってことは知らなくても怒られないんですからー。

係)お前を荒海に投げ込みたいよ…

な)え!?

係長のワンポイント

コメントは「何をしたか」を書く場所じゃない。
なぜそう書いたかを残すための場所だ。
*>は記号じゃなく、未来への合図だと思え。
CONTINUEの前に一行あるだけで、設計は“判断”になる。
読めるCOBOLは、コードより先にコメントが仕事をしている。

よかったらシェアしてね!
  • URLをコピーしました!
  • URLをコピーしました!

この記事を書いた人

コメント

コメントする