「Vistaでのゲーム開発で続発したトラブルの「笑えない原因」」記事へのコメント

笑うしかない人と、笑うに笑えない人と

[Anonymous Coward]

# タレコミ人です

本文に自分の感想をつらつら書くのもアレだったので省きましたが、個人的には、スライド [impress.co.jp]にある

動いていても信用ならない
バグはコピペで広がる
何かあるとOSのせいになる

というのが印象的でした。最後のはともかく、上の2つは大変ごもっともで。

また、本文には

これまでのIMM32は、このフラグを親切にも無視し続けていた

とありますが、どちらかというと「APIのバグを直したら、そのバグに依存して異常動作を免れていた他のコンポーネントが動かなくなった」という、これまたありがちな事態なのではないかと思います。

Re:笑うしかない人と、笑うに笑えない人と

[Anonymous Coward]

セキュリティの重鎮、高木先生がPHPの教本のサンプルからセキュリティホールが広がる可能性を示したエントリを書かれたことがあります。

プログラミング解説書籍の脆弱性をどうするか
http://takagi-hiromitsu.jp/diary/20051227.html

サンプルというのはその重要性とはうらはらに気軽に書かれ、そのくせ多くの人にコピペされて使われるものです。
最近はサンプルがサンプルであるがゆえにセキュリティ上脆弱であることを付記するドキュメントも増えましたが、これからは心あるプログラマは製品と同等にサンプルの品質にも気を配るべきなのでしょう。

サンプルコードの品質 (Re:笑うしかない人と、笑うに笑えない人と)

[fcp (32783)]

最近はサンプルがサンプルであるがゆえにセキュリティ上脆弱であることを付記するドキュメントも増えましたが、これからは心あるプログラマは製品と同等にサンプルの品質にも気を配るべきなのでしょう。

サンプルコードには目的があるので、その目的にどれだけ合っているかがサンプルコードの品質として非常に重要です。目的を無視して、そのまま使えるかどうかだけをサンプルコードの品質として見るならば、役に立つサンプルコードは書けなくなるでしょう。目的に合っているかどうかも含めて品質と呼ぶなら、サンプルコードの品質が重要なのはもちろんですし、これまでも重要性は認識されていた

Re:サンプルコードの品質 (Re:笑うしかない人と、笑うに笑えない人と)

[Anonymous Coward]

>後ろの章で文字列処理か入出力をきちんと取り扱う段階になって、
>初めて「じつは第 1 章に書いてあったプログラム 1.3 には
>問題があったのです」などと説明されるわけです。
>全部一度に説明しても理解できないので、
>これは悪くない方法だと思います。
いえ、悪い方法だとおもいます。
このような説明では「どこで読むのをやめてもＯＫ」なものを
示すべきです。
他に書きようがないなら、せめてそこに脚注等をつけ、
後まで読まないとまずいことを明示すべきでしょう。
ユーザが後ろの章まで読まずに、この部分を
そもままコピペしたらどうなるのでしょうか？
さらにそれが伝言ゲームで他人に伝わっていくとどうなるのでしょうか？

良い説明を書くには、穴がないように細心の注意を払います。
せめて教科書くらいは、そうあってほしいものです。

多分手にとった本がおなじかもしれないけど

[Anonymous Coward]

悪い例を載せたページには「悪い実装例です詳しい話は後で説明します」とか書いてあったと思う。

その章では、まずは大雑把にＣを理解しようとかだったかな？

##その本は、Ｃ言語とＣ＋＋言語を熟知している人が
書いたものだと感じた。

Re:多分手にとった本がおなじかもしれないけど

[fcp (32783)]

悪い例を載せたページには「悪い実装例です詳しい話は後で説明します」とか書いてあったと思う。

書いてあったかもしれません。憶えていません。

このようなサンプルコードがどれか 1 冊の本に書いてあったという印象ではなくて、あちこちの本に書いてあったような印象がありますが、この点についても記憶に自信があるわけではありません。