アカウント名:
パスワード:
動いていても信用ならないバグはコピペで広がる何かあるとOSのせいになる
これまでのIMM32は、このフラグを親切にも無視し続けていた
最近はサンプルがサンプルであるがゆえにセキュリティ上脆弱であることを付記するドキュメントも増えましたが、これからは心あるプログラマは製品と同等にサンプルの品質にも気を配るべきなのでしょう。
サンプルコードには目的があるので、その目的にどれだけ合っているかがサンプルコードの品質として非常に重要です。目的を無視して、そのまま使えるかどうかだけをサンプルコードの品質として見るならば、役に立つサンプルコードは書けなくなるでしょう。目的に合っているかどうかも含めて品質と呼ぶなら、サンプルコードの品質が重要なのはもちろんですし、これまでも重要性は認識されていた
悪い例を載せたページには「悪い実装例です詳しい話は後で説明します」とか書いてあったと思う。
書いてあったかもしれません。憶えていません。
このようなサンプルコードがどれか 1 冊の本に書いてあったという印象ではなくて、あちこちの本に書いてあったような印象がありますが、この点についても記憶に自信があるわけではありません。
いえ、悪い方法だとおもいます。 このような説明では「どこで読むのをやめてもＯＫ」なものを 示すべきです。
「べき」かどうかはスタンスの違いの問題です。僕は、入門書にもいろいろな種類があって良いと考えています。もちろん、どこで読むのをやめても間違った知識を持つことがないような入門書があっても良いですが、通読することを前提として、途中で読むのをやめたら間違った知識を持ってしまうかもしれないような入門書があっても良いと考えています。
他に書きようがないなら、せめてそこに脚注等をつけ、 後まで読まないとまずいことを明示すべきでしょう。
それも、「明示すべき」かどうかはスタンスの違いです。そのような状況で脚注等を付けない著者がいても、悪いとは僕は思いません。
ユーザが後ろの章まで読まずに、この部分を そもままコピペしたらどうなるのでしょうか？ さらにそれが伝言ゲームで他人に伝わっていくとどうなるのでしょうか？
仮にそうなってしまったら不幸なことですね。でも、入門書を途中まで読んだだけでプログラミング言語を理解できたと考えるような人には、その入門書は向いていなかったというだけのことです。そういう人もいるからというだけの理由で、すべての入門書はこうあるべきなどと規定するのは、つまらないと思います。
そもそもあのコードはコンパイル時にウォーニングが出るだろうから、ちゃんと脚注なりなんなりで説明しないとダメだよね。コンパイラの警告を無視するプログラマーを養成するつもりでないなら。
忘れていました。確かに今だと gets なんか使ったら Visual C++ でも gcc でも警告が出るでしょうね。 #1226028 [srad.jp] の例が今の時代に合っていないことはわかりました。ありがとうございます。
当時のコンパイラーでは gets 標準関数を使っても警告は出なかったと思います (少なくとも僕が使っていた Quick C コンパイラーでは、警告レベル最大でも出た記憶がありません)。 #1226028 [srad.jp] は「当時、あのような例を最初の方に載せて、後ろの章で『プログラム 1.3 はじつは駄目だった』と書いていた入門書は、悪くはなかった」という趣旨だとご理解ください。今同じコードを使って同じ説明をしたら、ご指摘のように、コンパイラーの警告が出るのに無視して進めることになってしまうので、当時とは状況が異なります。
>いえ、悪い方法だとおもいます。 >このような説明では「どこで読むのをやめてもＯＫ」なものを >示すべきです。 賛成です その部分だけ読んで使う人もいるでしょう、と言うより、かつて私もそうした覚えがあります。
>いえ、悪い方法だとおもいます。 >このような説明では「どこで読むのをやめてもＯＫ」なものを >示すべきです。
賛成です
その部分だけ読んで使う人もいるでしょう、と言うより、かつて私もそうした覚えがあります。
つまみ食いして使える本があるのは良いことだと思いますが、すべての本がつまみ食いする読者の役に立つ必要はないでしょう。僕は、つまみ食いする読者に害があるなら悪い本だ、という決め付けには反対です。
締め切りが迫っていたら、本を全部読んでから実装なんてのんきなことやってられませんから。
わかりますが、そういう状況では役に立たないような本があっても良いのではないでしょうか。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
私は悩みをリストアップし始めたが、そのあまりの長さにいやけがさし、何も考えないことにした。-- Robert C. Pike
笑うしかない人と、笑うに笑えない人と (スコア:4, 参考になる)
本文に自分の感想をつらつら書くのもアレだったので省きましたが、個人的には、スライド [impress.co.jp]にあるというのが印象的でした。最後のはともかく、上の2つは大変ごもっともで。
また、本文にはとありますが、どちらかというと「APIのバグを直したら、そのバグに依存して異常動作を免れていた他のコンポーネントが動かなくなった」という、これまたありがちな事態なのではないかと思います。
Re:笑うしかない人と、笑うに笑えない人と (スコア:2, すばらしい洞察)
プログラミング解説書籍の脆弱性をどうするか
http://takagi-hiromitsu.jp/diary/20051227.html
サンプルというのはその重要性とはうらはらに気軽に書かれ、そのくせ多くの人にコピペされて使われるものです。
最近はサンプルがサンプルであるがゆえにセキュリティ上脆弱であることを付記するドキュメントも増えましたが、これからは心あるプログラマは製品と同等にサンプルの品質にも気を配るべきなのでしょう。
サンプルコードの品質 (Re:笑うしかない人と、笑うに笑えない人と) (スコア:5, すばらしい洞察)
サンプルコードには目的があるので、その目的にどれだけ合っているかがサンプルコードの品質として非常に重要です。目的を無視して、そのまま使えるかどうかだけをサンプルコードの品質として見るならば、役に立つサンプルコードは書けなくなるでしょう。目的に合っているかどうかも含めて品質と呼ぶなら、サンプルコードの品質が重要なのはもちろんですし、これまでも重要性は認識されていた
Re:サンプルコードの品質 (Re:笑うしかない人と、笑うに笑えない人と) (スコア:1, 参考になる)
>初めて「じつは第 1 章に書いてあったプログラム 1.3 には
>問題があったのです」などと説明されるわけです。
>全部一度に説明しても理解できないので、
>これは悪くない方法だと思います。
いえ、悪い方法だとおもいます。
このような説明では「どこで読むのをやめてもＯＫ」なものを
示すべきです。
他に書きようがないなら、せめてそこに脚注等をつけ、
後まで読まないとまずいことを明示すべきでしょう。
ユーザが後ろの章まで読まずに、この部分を
そもままコピペしたらどうなるのでしょうか？
さらにそれが伝言ゲームで他人に伝わっていくとどうなるのでしょうか？
良い説明を書くには、穴がないように細心の注意を払います。
せめて教科書くらいは、そうあってほしいものです。
多分手にとった本がおなじかもしれないけど (スコア:1, 参考になる)
その章では、まずは大雑把にＣを理解しようとかだったかな？
##その本は、Ｃ言語とＣ＋＋言語を熟知している人が
書いたものだと感じた。
Re:多分手にとった本がおなじかもしれないけど (スコア:1)
書いてあったかもしれません。憶えていません。
このようなサンプルコードがどれか 1 冊の本に書いてあったという印象ではなくて、あちこちの本に書いてあったような印象がありますが、この点についても記憶に自信があるわけではありません。
Re:サンプルコードの品質 (Re:笑うしかない人と、笑うに笑えない人と) (スコア:1)
「べき」かどうかはスタンスの違いの問題です。僕は、入門書にもいろいろな種類があって良いと考えています。もちろん、どこで読むのをやめても間違った知識を持つことがないような入門書があっても良いですが、通読することを前提として、途中で読むのをやめたら間違った知識を持ってしまうかもしれないような入門書があっても良いと考えています。
それも、「明示すべき」かどうかはスタンスの違いです。そのような状況で脚注等を付けない著者がいても、悪いとは僕は思いません。
仮にそうなってしまったら不幸なことですね。でも、入門書を途中まで読んだだけでプログラミング言語を理解できたと考えるような人には、その入門書は向いていなかったというだけのことです。そういう人もいるからというだけの理由で、すべての入門書はこうあるべきなどと規定するのは、つまらないと思います。
Re:サンプルコードの品質 (Re:笑うしかない人と、笑うに笑えない人と) (スコア:0)
Re:サンプルコードの品質 (Re:笑うしかない人と、笑うに笑えない人と) (スコア:1)
忘れていました。確かに今だと gets なんか使ったら Visual C++ でも gcc でも警告が出るでしょうね。 #1226028 [srad.jp] の例が今の時代に合っていないことはわかりました。ありがとうございます。
当時のコンパイラーでは gets 標準関数を使っても警告は出なかったと思います (少なくとも僕が使っていた Quick C コンパイラーでは、警告レベル最大でも出た記憶がありません)。 #1226028 [srad.jp] は「当時、あのような例を最初の方に載せて、後ろの章で『プログラム 1.3 はじつは駄目だった』と書いていた入門書は、悪くはなかった」という趣旨だとご理解ください。今同じコードを使って同じ説明をしたら、ご指摘のように、コンパイラーの警告が出るのに無視して進めることになってしまうので、当時とは状況が異なります。
Re:サンプルコードの品質 (Re:笑うしかない人と、笑うに笑えない人と) (スコア:1)
>このような説明では「どこで読むのをやめてもＯＫ」なものを
>示すべきです。
賛成です
その部分だけ読んで使う人もいるでしょう、と言うより、かつて私もそうした覚えがあります。
数百ページのネットワークプログラミングの本だったと記憶しています。
締め切りが迫っていたら、本を全部読んでから実装なんてのんきなことやってられませんから。
Re:サンプルコードの品質 (Re:笑うしかない人と、笑うに笑えない人と) (スコア:1)
つまみ食いして使える本があるのは良いことだと思いますが、すべての本がつまみ食いする読者の役に立つ必要はないでしょう。僕は、つまみ食いする読者に害があるなら悪い本だ、という決め付けには反対です。
わかりますが、そういう状況では役に立たないような本があっても良いのではないでしょうか。
Re:サンプルコードの品質 (Re:笑うしかない人と、笑うに笑えない人と) (スコア:0)
こうしてなんだかわかんないけど動いてるソフトってのが増えるのかなと思いつつ、
そのコードを例示の意図を越えた使い方をするのは、使った人の判断だからね。
手を抜くのを止めはしないけどね。読んで理解するというコストを払えない人がいるなら、
理解することにコストかけてる人に発注した方が上質なソフトができてくるというのも理由があるわけだ。
Re:サンプルコードの品質 (Re:笑うしかない人と、笑うに笑えない人と) (スコア:0)
そんなのは、コーディングに入る前に読んでおくべきでしょ。
それに、サンプルコードが欲しいのなら教科書では無くて「ネットワークプログラミングサンプルコード集」を読むべきだったという点でも、選択が間違ってるよね。
教科書の使い方を学んでないのかな？
Re:サンプルコードの品質 (Re:笑うしかない人と、笑うに笑えない人と) (スコア:0)
のようないわゆる「リファレンス」本ならつまみ食いしてもいいと思いますが、
通読前提の「チュートリアル」本でそんなことするのは使い方を間違えてます。
ま、リファレンス本のサンプルコードにしても、
説明したいポイント以外のところはシンプルに書くのが普通ですから、
(でないと肝心の部分が明確に伝わらない)
一通り流さずに局所だけコピペするような使い方はやっぱり危険なわけで。
＃ こうして例外系をろくに考慮してないソースが生産されるわけか。
＃ 世に脆弱性の種は尽きまじ。
Re:サンプルコードの品質 (Re:笑うしかない人と、笑うに笑えない人と) (スコア:0)
> 後まで読まないとまずいことを明示すべきでしょう。
#1226028 のような記述は、体系を通して読む解説本のスタイル。
そして #1226059 のような記述は、つまみ読みするリファレンスのスタイル。
文書には意図に相応しい表現を用いるのだから、どっちがどうというものではないでしょう。
脚注で書いたところでコピペプログラマは読まないだろうと思うのでげんなりするわけですが。
# サンプルをコピペしたのに動かないと泣きつかれてもねえ。