アカウント名:
パスワード:
まだ紹介されていないようなので。
「デバッグパターン」 [fc2web.com]
このストーリーで紹介された手法のかなりの部分が、ここですでに網羅されています。
中でも身につまされたのが、これ。
名称：PhenomenonDebug アンチパターン 別名： 対処療法アンチパターン、もぐら叩きアンチパターン 例： 「ここの関数に来る値がときどき一文字欠けているんだ。欠けている文字が何か推測するプログラムを書くのに苦労したよ。」 分類： ３．プログラマのバグ 現象： プログラムの現象に対する修正を行う。 原因： 現象はなぜ起こったのかという原因を修正せずに、その現象に対する修正を行ってしまう。 対策： 原因に対する修正を行う。ある関数に必ず2倍の値が入ってくるのならば、入ってきた値を1/2にするのではなく、2倍の値が入ってくる原因を修正する。 例外： 原因を自分が触れることができない場合はその限りではない。が、後の人のために必ずコメントを入れておかねばならない。 補足： このアンチパターンを行うプログラマは転職を真剣に考えるべき。というか消えてください。
（末尾の強調は引用者による）
その昔volatile宣言が無かったころに, なんか変なおまじないコーディングをやっていた記憶があります. 確かRS-232Cか何かでそれほどタイミングには煩くなかったので, それですんじゃってたんですね.
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
日々是ハック也 -- あるハードコアバイナリアン
デバッグパターン (スコア:5, 参考になる)
まだ紹介されていないようなので。
「デバッグパターン」 [fc2web.com]
このストーリーで紹介された手法のかなりの部分が、ここですでに網羅されています。
中でも身につまされたのが、これ。
（末尾の強調は引用者による）
Re:デバッグパターン (スコア:3, おもしろおかしい)
c = c / 2; /* 答えが倍になるため */
ってソースをスタッフが書いてました orz
で、そいつは
a = b + 1;
a = b + 1; /* 念のため。たまに答えがおかしいので */
ってコードも書いてました orz
みんつ
ローストビーフの両端を切り落とす (スコア:2, 興味深い)
> a = b + 1; /* 念のため。たまに答えがおかしいので */
> ってコードも書いてました orz
組込み分野では笑えません．
デバイスレジスタには2度書くというおまじないを，大マジメにやっている人々が結構います．クルマ方面とか．
from もなか
Re:ローストビーフの両端を切り落とす (スコア:1)
その昔volatile宣言が無かったころに, なんか変なおまじないコーディングをやっていた記憶があります. 確かRS-232Cか何かでそれほどタイミングには煩くなかったので, それですんじゃってたんですね.
Re:ローストビーフの両端を切り落とす (スコア:0)
これもある意味おまじないだと思う。
Re:ローストビーフの両端を切り落とす (スコア:1)
a = b + 1;
c = b + 1;
assert( a == c);
超冗長というキーワードで，マジメに議論している人々がいます，という話を先日聞いて，ココロに衝撃が走りました．
けれど，デバイスレジスタに2度書きするのと同様，私には笑えません．
# 社員一同，マトモに動きゃしない試作品のMPUと闘う半年だったID
from もなか
わらえないひとは・・ (スコア:0)
プロだと思います。
最初アセンブリする前のコードを見たとき
似たような気持ち（まちがっとる！！おまえ馬鹿だなぁ！！）になりましたが
実際安定して動いているものを見ると
なぜそうなのかがわからなく なにもいえませんでした。
プロ曰く、もし挙動が知りたいなら、全パターンを徹底的に
チェックするべきといっていました
Re:ローストビーフの両端を切り落とす (スコア:0)
もにたようなもんだと思ったり。
Re:ローストビーフの両端を切り落とす (スコア:0)
量産品でも、現象をとらえるトリガ条件のためにFPGAを使ったり。
結局、MPUのバグ(;; でも、製品出荷後にerattaを更新されるなんて...。
Re:ローストビーフの両端を切り落とす (スコア:0)
ものによってはそういうのもアリかな～と思ったり。
#80386のプリリリース版使って、作ってる製品のデバッグだか
#CPUのデバッグだか分かり難い状況の経験等あるんで。
ま、この場合の2度書きの真意次第でしょうけど。
Re:ローストビーフの両端を切り落とす (スコア:0)
…ソレって解決になってるのか？とか思いましたが。
Re:ローストビーフの両端を切り落とす (スコア:0)
Re:ローストビーフの両端を切り落とす (スコア:0)
ウェイト時間を稼ぐ為にその様にする事も有るかと思います。
組み込み系や、ファームウェアに近いプログラムを書いたことがある人ならご存じの人も多いと思いますが、周辺IOへの書き込みは数μ秒待ってから行わなければならない事がありますが、このウェイト時間を稼ぐ為に無意味なデバイスレジスタへの書き込みを行う場合もあります。
少々古い話になりますが、PC-9801シリーズにもウェイト用のIOポートが用意されていました。
サウンドドライバ等ではウェイト用IOポートを使ってウェイトを確保するのがセオリーでした。
V30時代の古いゲームで使用されたサウンドドライバなどは音源チップへの書き込み時に必要なウェイトを単純ループで確保していた為に、CPUが速くなったときにドライバが転けてしまう物もありました。
Re:ローストビーフの両端を切り落とす (スコア:1)
ええ．全てはハードウェア次第です．
例えばUARTの出力レジスタに2度書きするのは，大抵の場合，間違いです．
前提がなければエレガントとも間違えているとも言えないはず．笑えないし，肩も持てない．
# MinixカーネルのハックでPC-9801は散々触ったID
from もなか
Re:ローストビーフの両端を切り落とす (スコア:0)
Re:ローストビーフの両端を切り落とす (スコア:0)
Re:ローストビーフの両端を切り落とす (スコア:0)
それは仕様とは言わないと思う。
普通は実装依存とか、仕様で定義されていない振る舞いに依存しているとか。ってか、「仕様書外の仕様」がまかり通るなら仕様書を一枚も書かなくても仕様が定義できた事になって嬉しいかも。
ハードは直せない罠（Re:デバッグパターン） (スコア:1)
/* インターフェースのボードがタコでさぁ……*/
for (i = 1 ; i = 10 ; i ++){
if( GPIBインターフェースのオープンの関数を呼ぶ ){
printf("%d 回目にインターフェースのオープンに成功しました\n", i);
成功したってフラグ立ててから
break;
}
}
if(結局成功してなかったら)
printf(”10回やってもダメでした。電源入れ直しからやってください\n”);
exit();
}
確かこんな感じで測定のプログラムを作った記憶が。
Re:デバッグパターン (スコア:1)
例： 「ああ、また受注品目の入力ミスした人がいるな…」
分類： ３．主に本社の中の人のバグ
現象： プログラムの現象に対する修正を行う。
原因： 現象は判っているが手入力の都合（と上流のシステム）が原因。無限大の可能性を秘めているが修正しないと動かないので現象に対する修正を行ってしまう。
対策： 主に本社の中の人に苦情を出す。
例外： 部長以上の場合は触れない。若しくは、当たり障りの無い程度にコメントを残す。
補足： 手入力は永久に消えないので、現象の修正を行う場合には出来るだけ多くのパターンを弾き出して当分大丈夫な状態にすること。
本社の中の人が入力する為のシステムは、15年近く前に退職しましたアンチパターンにより発生している為、手が出無いので注意。
#なんとなく、ごめんなさいごめんなさいごめんなさい。
#本社のシステムなんて、担当すら曖昧で触れる人居なくて触って止まったら終わりです…
#誰だよこんなの作ったやつは _|￣|○
Re:デバッグパターン (スコア:0)
3日ほど唸った挙句に出てきたコードを見たら、
単にcatchが追加されていただけだったので、愕然とした覚えがあります。
氏ね！あほ！ボケ！カス！間抜け！ (スコア:0)
消えてくださいという日本語は難しいもので
本気で言ったら 退職しやがった