「コメントはソースコードを表す？」記事へのコメント

良い言い訳

[s02222 (20350)]

> コメントに言い訳まがいのくどい説明

出来る限りの最適化を加えてた結果としてどうしょうもなく読みにくくなって、それを緩和すべくくどい説明を添えることぐらいは許してください。

単純なところでは、

strcpy(dst + a + b + c, src); // 意図はstrcat(dst, src); ここまでの処理でstrlen(dst) == a + b + cなので

みたいな、(この例だと変数名が最悪なのは置いといて)分かってる値を使い回してステップ数を減らすところから、もっと凝りに凝った最適化まで。

ぱっと見て何が書いてあるのか分からない、

Re:良い言い訳

[Anonymous Coward]

>strcpy(dst + a + b + c, src); // 意図はstrcat(dst, src); ここまでの処理でstrlen(dst) == a + b + cなので
この程度の最適化はコンパイラに任せるべきだと思うし、コメントよりも
const int offset_ここまでの処理でずれたと言うことがわかる名前 = a + b + c;
strcpy(dst + offset_ここまでの処理でずれたと言うことがわかる名前, src);

とかするとソースコードが意図を見せてくれると思うのだけどそういうのじゃだめなの？

Re:良い言い訳

[s02222 (20350)]

>const int offset_ここまでの処理でずれたと言うことがわかる名前 = a + b + c;

なるほど。・・・ただその場合、「この変数はソースを見やすくするためだけのものです」とのコメントがないと混乱しそうな気がするんですが、そういう気がするのがもはや時代遅れなのかなorz

Re:良い言い訳

[taka2 (14791)]

オフセットな変数を一時しのぎに作るから混乱するんでしょう。最初から

strcpy(dst+dst_offset, src_a); dst_offset += length_a;
strcpy(dst+dst_offset, src_b); dst_offset += length_b;
strcpy(dst+dst_offset, src_c); dst_offset += length_c;

って感じでやってれば問題ないかと。printf系は格納した文字数を返すので、この方法だと、

dst_offset+=sprintf(dst+dst_offset, "%d", value);

って出来て便利。最も、バッファオーバーフロー対策でsnprintfを使ったりすると、snprintfは「書き込んだ文字数」ではなく「必要な長さ」を返すので、この技が使えず、

snprintf(dst+dst_offset, dst_rest, "%d", value); len = strlen(dst+dst_offset); dst_offset += len; dst_rest -= len;

見たいな、効率面でダメダメなコードを書いたりすることもあったり。

Re:

[Anonymous Coward]

つーか
sprintf(dst, "%s%s%s", src_a, src_b, src_c);
じゃダメなの?
オフセットを自前で管理してまでstrcpyやsprintfで1つずつコピーしていくのってCプログラミング診断室で見たダメな実例 [kojima-cci.or.jp]そのまんまなんだけど。

Re:

[Anonymous Coward]

途中から元コメの意図と微妙にずれていくソースコードの件に関して。

# こうしてバグが生み出されて行く。

Re:

[Anonymous Coward]

コンパイラが馬鹿な場合、最適化が全然聞かなかったりして、本気で頭くる。
こっちは複雑な処理だからシンプルで直感的なコード書きてーんだ、
なに？ この程度のforループの最適化もしてくんないの？
え？ このforループ一個だけで処理速度全体が1/3になった？
キャッシュのヒット率か？
しょーがねーから膨大なプロジェクト全体のfor文全部見直し、
マジっすか？？ 何個あんの？？
パフォーマンスが出ねーんだよしょーがねー！！！

という修羅場（全部実話）の後のコードは、コメント無しじゃどうしようもない。
残念ながらいつもコンパイラが最適化やってくれるとは限らないっす。