組み込みプログラミングのコメントについて

Question

いつもお世話になっております。

組み込み時のプログラミングについての質問です。

組み込みでのプログラミングは処理を早くしたり、使うメモリを減らすためにできるだけ短く
コーディングするというようになっていると思います。しかし、私はまだ初心者なのでぱっと見
ではわからない処理が多く、それなりの頻度でコメントを書いています。

このコメントを書くという行為は、組み込みのコーディングにおいては
余分なデータ(コメントなのでコードではないと思いました)という扱いになるのでしょうか？
つまり、コメントを書くことでコーディングできる領域を圧迫しているのでしょうか？

組み込みについては初心者なので、初歩的な質問かもしれませんがご教授いただけると幸いです。

Answer 1

「昔はリソースが貧弱だったので、なるべくコードを短く書いた」のような話を聞いて
「組み込み = リソースが貧弱 = 短く書く」と思ったのかもしれません。
しかし、「昔はリソースが貧弱だったのでなるべくコードを短く書いた」と言うのは
コードを書く環境が貧弱だったという話です。
要するにコードが長いとエディタで読み込むのが時間かかるとか
モニタに表示できる文字数が限られているので見づらいとか、
コンパイラが読み込むのが時間かかるとか、
保存するときにファイルサイズが気になるとかそういう話です。

組み込みだったら大抵の場合、最終的に機械語になるので、
コメントが長いとかどうでもいいです。

Comments

[poemt]

私の間違った思い込みだったみたいですね。
回答していただきありがとうございます。

Answer 2

ほとんどの場合、組み込み環境で直接インタプリタを動かすことはなく、書いたプログラムは事前に実行形式（あるいはJavaバイトコードのような中間形式）に変換してから組み込まれることになります。

その変換の過程でコメントなどは削られますので、実機での動作に悪影響をおよぼすようなことはほぼありません。

Comments

[poemt]

ありがとうございます。
コメントを書きすぎてしまったらどうしようかと思っていたのですが、杞憂だったみたいで安心しました。

わかりやすい回答を3つも頂いたのですが、もっとも早かったこちらの回答をベストアンサーにしたいと思います。

Answer 3

余分なデータ(コメントなのでコードではないと思いました)という扱いになるのでしょうか？

そんなことはないので、気にせずコメントを書いてください。
コンパイル時にコメントは無視されますので、どんなにたくさん（長い）コメントを書いても実行モジュールのサイズには影響しません。

もし興味がおありなら、同じコードでコメント無しのソースとものすごくたくさんのコメントを付けたソースをコンパイルして、出力されたモジュールのサイズを比較してみると良いでしょう。

Comments

[poemt]

回答していただきありがとうございます。
コンパイル時に行われることについて無知だったのですが、そのようになっていたんですね。勉強になります。

Answer 4

既に解決済みですが、ご参考までに少し補足致します。

組み込み系で良く使用されるC言語の例を念頭に置いて記載していますが、コンパイラ言語にはほぼ共通です。

多くの処理系では、コンパイラによって処理される前にプリプロセッサによって前処理が行われます。
その際、例えばヘッダーのインクルードが行われますが、同時にコメントや余分な空白等も削除されます。
従って、コンパイル結果であるバイナリの実行モジュールにはコメントは含まれませんし、分かりやすいように長い変数名を使用したとしても参照先を示すアドレス値に置き換えられてしまうので、サイズが大きくなってしまうと言うこともありません。勿論、実行速度にも影響しません。

いわゆる逆コンパイラによってソースコードに戻しても、無味簡素な記号の羅列になってしまうというのも、そこに原因があります。

さて、開発やテストという観点で言えば、環境は昔と大きく変わりました。

実際に実行されるハードウェアのことをtターゲットマシンと呼びますが、初期の頃は非力なターゲットマシンが全てであり、ろくなツールも無しに開発もテストも全てをターゲットマシン上でやっていました。しかも、メインメモリーの容量が64キロバイトというのが贅沢な環境でしたから、コメントを付けるどころではありませんでした･･･

しかし今や、実機（ターゲットマシン）でのテストは開発がかなり進んでから実施されます。そして、開発（そしてテストの多くの部分も）は専ら高性能PC上に構築されたクロス開発環境で実施されます。
そこには強力なデバッガー等のツール類が完備しているだけでなく、高性能のシミュレーターによってハードウェアの挙動までもシミュレーションしてくれます。

ですから、開発時にリソース不足を気に掛ける必要は滅多に無いと言えます。

ところが、システムは巨大化・複雑化する一方なのに仕様変更が後を絶たない状況なので、設計書を含めたメンテナンス性の問題がクローズアップされるようになっています！

実際の仕様（ソースコード）と乖離してしまった設計書ほど厄介なモノはありません。しかし、詳しく書けば書くほどメンテナンスコストも高くなります。

とりわけ詳細設計書はソースコードとの関連性が強いため、ちょっとした改修に対しても都度修正が必要になりますが、得てして体裁を整えるためだけの（実際には使用されない）後追いでの改修作業が延々と繰り返されるだけになってしまうケースも散見されます。

そこで、詳細設計書として必要不可欠の情報のみを厳選し、コメントとしてソースコードに埋め込んで管理しようとする試みも一部では行われています。

勿論、たくさん書き過ぎると可読性が低下すると共にメンテナンスコストも高くなりますから、ソースコードを読めば分かる事は書かない、むしろロジック等はコメント無しでも分かるような実装を心掛けるべきです。
しかし、その様な仕様になった経緯や実装上の制約条件、ファイル処理のセクションでは処理前後のフォーマットの変化などをメモしておくことで、Excel方眼紙でコテコテに書き上げられた嘘の設計書よりも遥かに有用で信頼性の高い設計書とする事が出来ます。

ソースコードを読む時には常に傍らにあり、diffを取れば必ずソースと設計書の差分がセットで得られるというのは、この上なく大きなメリットです。

以上、ご参考まで。

Comments

[poemt]

改修するときのことを考えると、コメントは不可欠なものなのですね。
バージョン管理して作業している場合などはたしかにコメントに残してあるほうが設計書よりも頼りになりそうです。

現状に至るまでの経緯と補足、ありがとうございます。勉強になりました。