アカウント名:
パスワード:
動いていても信用ならないバグはコピペで広がる何かあるとOSのせいになる
これまでのIMM32は、このフラグを親切にも無視し続けていた
最近はサンプルがサンプルであるがゆえにセキュリティ上脆弱であることを付記するドキュメントも増えましたが、これからは心あるプログラマは製品と同等にサンプルの品質にも気を配るべきなのでしょう。
サンプルコードには目的があるので、その目的にどれだけ合っているかがサンプルコードの品質として非常に重要です。目的を無視して、そのまま使えるかどうかだけをサンプルコードの品質として見るならば、役に立つサンプルコードは書けなくなるでしょう。目的に合っているかどうかも含めて品質と呼ぶなら、サンプルコードの品質が重要なのはもちろんですし、これまでも重要性は認識されていた
>いえ、悪い方法だとおもいます。 >このような説明では「どこで読むのをやめてもＯＫ」なものを >示すべきです。 賛成です その部分だけ読んで使う人もいるでしょう、と言うより、かつて私もそうした覚えがあります。
>いえ、悪い方法だとおもいます。 >このような説明では「どこで読むのをやめてもＯＫ」なものを >示すべきです。
賛成です
その部分だけ読んで使う人もいるでしょう、と言うより、かつて私もそうした覚えがあります。
つまみ食いして使える本があるのは良いことだと思いますが、すべての本がつまみ食いする読者の役に立つ必要はないでしょう。僕は、つまみ食いする読者に害があるなら悪い本だ、という決め付けには反対です。
締め切りが迫っていたら、本を全部読んでから実装なんてのんきなことやってられませんから。
わかりますが、そういう状況では役に立たないような本があっても良いのではないでしょうか。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
Stableって古いって意味だっけ？ -- Debian初級
笑うしかない人と、笑うに笑えない人と (スコア: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:笑うしかない人と、笑うに笑えない人と) (スコア:1)
>このような説明では「どこで読むのをやめてもＯＫ」なものを
>示すべきです。
賛成です
その部分だけ読んで使う人もいるでしょう、と言うより、かつて私もそうした覚えがあります。
数百ページのネットワークプログラミングの本だったと記憶しています。
締め切りが迫っていたら、本を全部読んでから実装なんてのんきなことやってられませんから。
Re:サンプルコードの品質 (Re:笑うしかない人と、笑うに笑えない人と) (スコア:1)
つまみ食いして使える本があるのは良いことだと思いますが、すべての本がつまみ食いする読者の役に立つ必要はないでしょう。僕は、つまみ食いする読者に害があるなら悪い本だ、という決め付けには反対です。
わかりますが、そういう状況では役に立たないような本があっても良いのではないでしょうか。
Re:サンプルコードの品質 (Re:笑うしかない人と、笑うに笑えない人と) (スコア:0)
こうしてなんだかわかんないけど動いてるソフトってのが増えるのかなと思いつつ、
そのコードを例示の意図を越えた使い方をするのは、使った人の判断だからね。
手を抜くのを止めはしないけどね。読んで理解するというコストを払えない人がいるなら、
理解することにコストかけてる人に発注した方が上質なソフトができてくるというのも理由があるわけだ。
Re:サンプルコードの品質 (Re:笑うしかない人と、笑うに笑えない人と) (スコア:0)
そんなのは、コーディングに入る前に読んでおくべきでしょ。
それに、サンプルコードが欲しいのなら教科書では無くて「ネットワークプログラミングサンプルコード集」を読むべきだったという点でも、選択が間違ってるよね。
教科書の使い方を学んでないのかな？
Re:サンプルコードの品質 (Re:笑うしかない人と、笑うに笑えない人と) (スコア:0)
のようないわゆる「リファレンス」本ならつまみ食いしてもいいと思いますが、
通読前提の「チュートリアル」本でそんなことするのは使い方を間違えてます。
ま、リファレンス本のサンプルコードにしても、
説明したいポイント以外のところはシンプルに書くのが普通ですから、
(でないと肝心の部分が明確に伝わらない)
一通り流さずに局所だけコピペするような使い方はやっぱり危険なわけで。
＃ こうして例外系をろくに考慮してないソースが生産されるわけか。
＃ 世に脆弱性の種は尽きまじ。