アカウント名:
パスワード:
動いていても信用ならないバグはコピペで広がる何かあるとOSのせいになる
これまでのIMM32は、このフラグを親切にも無視し続けていた
最近はサンプルがサンプルであるがゆえにセキュリティ上脆弱であることを付記するドキュメントも増えましたが、これからは心あるプログラマは製品と同等にサンプルの品質にも気を配るべきなのでしょう。
サンプルコードには目的があるので、その目的にどれだけ合っているかがサンプルコードの品質として非常に重要です。目的を無視して、そのまま使えるかどうかだけをサンプルコードの品質として見るならば、役に立つサンプルコードは書けなくなるでしょう。目的に合っているかどうかも含めて品質と呼ぶなら、サンプルコードの品質が重要なのはもちろんですし、これまでも重要性は認識されていた
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
最初のバージョンは常に打ち捨てられる。
笑うしかない人と、笑うに笑えない人と (スコア:4, 参考になる)
本文に自分の感想をつらつら書くのもアレだったので省きましたが、個人的には、スライド [impress.co.jp]にあるというのが印象的でした。最後のはともかく、上の2つは大変ごもっともで。
また、本文にはとありますが、どちらかというと「APIのバグを直したら、そのバグに依存して異常動作を免れていた他のコンポーネントが動かなくなった」という、これまたありがちな事態なのではないかと思います。
Re:笑うしかない人と、笑うに笑えない人と (スコア:2, すばらしい洞察)
プログラミング解説書籍の脆弱性をどうするか
http://takagi-hiromitsu.jp/diary/20051227.html
サンプルというのはその重要性とはうらはらに気軽に書かれ、そのくせ多くの人にコピペされて使われるものです。
最近はサンプルがサンプルであるがゆえにセキュリティ上脆弱であることを付記するドキュメントも増えましたが、これからは心あるプログラマは製品と同等にサンプルの品質にも気を配るべきなのでしょう。
サンプルコードの品質 (Re:笑うしかない人と、笑うに笑えない人と) (スコア:5, すばらしい洞察)
サンプルコードには目的があるので、その目的にどれだけ合っているかがサンプルコードの品質として非常に重要です。目的を無視して、そのまま使えるかどうかだけをサンプルコードの品質として見るならば、役に立つサンプルコードは書けなくなるでしょう。目的に合っているかどうかも含めて品質と呼ぶなら、サンプルコードの品質が重要なのはもちろんですし、これまでも重要性は認識されていた
Re:サンプルコードの品質 (Re:笑うしかない人と、笑うに笑えない人と) (スコア:1, 参考になる)
>初めて「じつは第 1 章に書いてあったプログラム 1.3 には
>問題があったのです」などと説明されるわけです。
>全部一度に説明しても理解できないので、
>これは悪くない方法だと思います。
いえ、悪い方法だとおもいます。
このような説明では「どこで読むのをやめてもＯＫ」なものを
示すべきです。
他に書きようがないなら、せめてそこに脚注等をつけ、
後まで読まないとまずいことを明示すべきでしょう。
ユーザが後ろの章まで読まずに、この部分を
そもままコピペしたらどうなるのでしょうか？
さらにそれが伝言ゲームで他人に伝わっていくとどうなるのでしょうか？
良い説明を書くには、穴がないように細心の注意を払います。
せめて教科書くらいは、そうあってほしいものです。
Re:サンプルコードの品質 (Re:笑うしかない人と、笑うに笑えない人と) (スコア:0)
> 後まで読まないとまずいことを明示すべきでしょう。
#1226028 のような記述は、体系を通して読む解説本のスタイル。
そして #1226059 のような記述は、つまみ読みするリファレンスのスタイル。
文書には意図に相応しい表現を用いるのだから、どっちがどうというものではないでしょう。
脚注で書いたところでコピペプログラマは読まないだろうと思うのでげんなりするわけですが。
# サンプルをコピペしたのに動かないと泣きつかれてもねえ。