コメントの話
前回，trackはプログラミングスキルの可視化と測定を目指していると書きましたが，測定の自動化が難しいものもあります．それは，前回紹介した「プログラミング」の入試における8個の測定項目の特に最後の2つ
(7) 適切なドキュメント (コメント) を自然言語で書ける能力
(8) 自分の書いたプログラムについて口頭で説明できる能力
です．今回はこのうちの(7)，つまりコメントを（自然言語と限らず）書ける能力について少し深堀りしてみましょう．
情報量ゼロのコメント
コメントというと，プログラムを読みやすくするためのものというのが一般的な常識でしょう．確かにコメントがきちんと書かれたプログラムは，コメントのまったく書いてないプログラムに比べると読みやすいことは事実です．
しかし，例外もあります．いまから40年近く前，私はNTTの新米研究者でしたが，とある事情で，小さなソフトハウスの若いプログラマの丁稚奉公のお手伝いを横から見ることがありました．正確には覚えていませんが，彼の書いたプログラムに以下のような1行がありました．
x=x+1 // xに1を足す
ほかの行もすべからくこんな調子でした．あちゃあです．間違いなく自然言語で書かれていて，コメント風の見掛けですが，情報量がゼロです．こういうコメントなら書かないほうがましです．しかし，このコメントが
x=x+1 // x座標を1つ右にずらす
だったらどうでしょう．これは，「x=x+1」よりはるかに大きな情報量を持っています．つまり，コメントとしての価値があります．
コメントはプログラムのそれぞれのステップ，あるいはモジュールの「意味」や「意図」を伝えるものでなくてはいけません．
コメントは誰のためのものか
意味や意図を伝えるコメントを書くと，プログラムは読みやすくなります．プログラムを読む人は，プログラム本体の字面を追うと同時に，コメントを読み，コード本体の意図を理解しようとします．コメントがないと，読む人はプログラマの意図を自分で再構成しないといけません．
それはそうなのですが，コメントは読む人のためだけのものなのでしょうか？ 私は違うと思っています．実はプログラムを書く人のためのものでもあります．特にプログラムを書いて，テストやデバグしているときは，ほぼ書く人のためのものです（作成中にレビューする人がいれば，その人が読んで理解するためのものでもあります）．
毎日のようにプログラムを書いていたころの私のプログラミングのスタイルは，以下の通りでした．
(1) 書くプログラムのデータ構造の設計を，（特に機械語レベル以下の低レイヤ言語で書く場合）なるべく図式的に書きます．
といっても，ASCIIコードで書けるような程度の図です．私はアルゴリズム自体を書くことはほとんどしませんでした．データ構造を決めれば，最適なアルゴリズムがほぼ自動的に決まるからです．実は話は逆で，アルゴリズムを頭の中で考えてから，それに相応しいデータ構造を決めていました．大きいシステムを作る場合は，この部分にかなりの時間を割きました．場合によっては200ページを超すようなドキュメントをまず書きました．この段階での設計ミスはもちろんあり得ますが，その手のミスはほとんどなかったと記憶しています．
(2) あとは一番難しい部分から少しずつ，しかし一気呵成にプログラムを書いていきます．
プログラムのモジュールの頭にはこれが何をするモジュールなのかのコメントはまず書きますが，コードの各行にコメントを書くことはほとんどしません．
(3) 短期記憶の範囲で一気呵成に書いたプログラムを，デバグのために見直すときに詳細なコメントを書いていきます．
これがバグの発見に最も役立ちました．つまり，デバグの作業としてのコメント書きなのです．
(4) このあたりが一段落したところで，モジュールテストを行います．このように(2)～(4)を繰り返していきます．
こういったスタイルがベストと言うつもりはありませんが，プログラミングの作法で迷っている人には参考になるかもしれません．
デバグ作業としてのコメント
デバグ作業としてのコメント書きでは，x=x+1を「xを1増やす」とコメントしてはいけません．まったくデバグにならないからです．なぜ，そこでxを1増やしたのかの意味や意図をプログラムの中にコメントとして定着させるというか焼き付けることが大事なのです．
チンプンカンプンでいいのですが，昔私が書いた（実時間ゴミ集めのための）マイクロプログラムの断片を見てください．セミコロンの右側がコメントです．
スタックポインタを5語分減らすというたった1ステップに4行もコメントが書かれています．しかもプログラムに出てこない変な単語や略語が一杯書かれています．意図を明確にするためにはどうしてもこれだけのコメントを書かないといけなかったのでした．一気呵成に書いた3行のコードが，デバグコメント作業で7行にも膨れ上がったわけです．
デバグコメントを書いているときに，ちょっとした書き間違いや抜けが発見されるのはもちろんですが，より良い最適化が見つかることもあります．
プログラミング言語と自然言語による複眼思考
コメントを書くことは，実は同じことをまったく異なる2通りの言語で書くことに通じます．例えば，実行プロセスをプログラミング言語で書くのと，プログラムの実行によってもたらされる状態の変化を論理式で書くのとでは，まさにまったく違う言語で同じことを書こうとしています．もちろん，これほど極端に違う書き方をいつもしないといけないわけではなくて，「x座標を1つ右にずらす」でも十分です．
日本語の論文を書くときに，まず英語で書いてから，それを日本語に直すという方法があります．英語で書くほうが，論文を書く作法に沿ったものになりやすいという「現象」があるからです．ともかく日本語と英語の両方で書くと，いろいろな誤りや抜けが発見しやすいのは事実です．
複眼思考という言葉があります．同じものを多面的に捉えることによって，より正確，かつ創造的な思考ができる方法のことですが，プログラムをコード本体とコメントという2面から捉えることによって，より早く正しいプログラムに到達できることを示唆しています．
上でちょっとだけ見せた「実時間ゴミ集め」は私の経験上最も強烈なプログラムでした．3日間苛酷なテストプログラムを走らせて初めて出てくるバグがあったりして，デバグにかなり苦労しました．このときだけは，プログラムの中のあちこちにたくさんの論理式をコメントとして散りばめました．それとプログラムを睨めっこしてプログラムを修正したのです．それでも長時間走らせるとバグが出ることがありました．論理式のほうに抜けがあったのです．
論理式も正しく意図を反映して書くのはやさしくありません．それでも，プログラムを2通りの見方で捉えるのは正しいプログラムへの近道になります．コメントはそのためのとてもいい手段なのです．もちろん，読解の補助としての役割を忘れてはいけません．なお，コメントの量が多ければいいというものでもありません．書きすぎるとうざくなります．
良いコメントなのか，価値のないコメントなのかの判断はそう簡単ではありません．究極の人工知能の問題と言えるでしょう．trackもさすがにそのあたりは深追いできません．しかし，採用を担当する熟練エンジニアがtrackに提出されたプログラムをちょっと見れば，かなりの正確さでコメントの品質を判定することができ，プログラミングの実力もついでに判定できると思います．ぜひ，コメントも気を抜かずに書いてください．
