Writing Bug Free C code chapter 1 Understand Why Bugs Exist
6144 ワード
title: Writing Bug Free C code chapter 1 Understand Why Bugs Exist date: 2017-06-13 18:26:31 tags:
この翻訳は参考にしてください/ブログは数を集めます/多数の翻訳は意訳で、持っていない部分は英語の原文をプラスします
Chapter 1:Understand Why Bugs Exist/なぜバグがあるのか理解
ソフトウェア開発の反復の中でどうしていつもバグがこっそり入ってくるのですか?なぜbugが存在するのかを理解するのに時間がかかるのはbug-freeコードを書く最初のステップです.第2歩は、問題/検出問題を減らすための行動策定戦略をとることです.さらに重要なのは、チーム全体にこれらの新しい戦略を理解させることです.
筆者の親友は特別な会社で働いており、彼が書いたコードとモジュールに対してランタイムパラメータチェック(run-time parameter validation)を使用します.これは良いアイデアですが、このような強制的なやり方は他のプログラマーをあまり望んでいないかもしれません.ある日、友达は古いコードを少し修正して、パラメータチェックを加えました.彼はコードをテストしてコードライブラリに転送し、数週間後にこのコードが古いコード(1年前の)を呼び出すとパラメータエラーが表示されます.しかし、一部のプログラマーはこのパラメータをチェックアウトしたいと思っています.彼らはエラーログの印刷があると思っています.古いコードに問題があるわけではありません.新しいパラメータの検証が間違っているに違いありません.
これは極端な例ですが、1つのプログラミングプロジェクトでチーム全員にこの戦略の実施を理解させなければならないことを説明するのに十分です.
1.1小項目vs.大項目
hex dumpツール(DUMPと呼ばれる)を書く必要がある場合は、コマンドラインに表示したいファイルの名前をパラメータとして受信する必要があります.バグのないコードを書くことができますか?もしかすると、このプロジェクトは小さいので、定義がよくて隔離してもインタラクションがありません.
だから、ALPHAというプロジェクトを書くように要求されたら、あなたの会社は他の会社が持っているプロジェクトに集中します.このプロジェクトには数百行以上のコードが必要で、すでに10人のプログラマーがこのプロジェクトで働いています.納期はもうすぐです.会社にはあなたの知恵が必要です.すぐにこのチームに飛び込み、新しいコードを書き、バグを導入しないと思いますか.私にはできません.間違いを捕まえる方法がなければ、どんな初心者でもバグを導入します.
あなたが今処理している最大のプロジェクトを考えてみてください.どれだけのヘッダーファイルがあり、ヘッダーファイルには何がありますか.ソースファイルはいくつありますか.そして、中には何がありますか.DUMPという小さなツールを処理するのは問題ありませんが、なぜこの大きなプロジェクトを処理するのがこんなに難しいのですか?どうして大きなプロジェクトは10個100個の小さなプロジェクトほど簡単ではありませんか.
私たちはあなたの小さなプロジェクトを研究します.いくつかのヘッダファイルと実装ファイルから構成され、ヘッダファイルには関数のプロトタイプ、データ構造宣言、マクロ定義、typedef定義などがあり、ファイルが十分に少ないため、処理することができます.今、それを10に100を乗じると、突然このプロジェクトは管理できなくなります.
あなたのヘッダーファイルには管理するものがたくさんあります.このプロジェクトはサポートが必要です.人数を増やしてこのプロジェクトを処理すると、より速く完成しますが、これは問題を深刻化させるだけです.今、より多くの人がヘッダーファイルに情報を追加し、他の人が理解する必要があります.これはすべての大きなプロジェクトが悪循環に陥っているからです.
1.2ヘッダファイルにデータ構造が多すぎる
大きなプロジェクトでは、データ構造を熟知するのに時間がかかるという明らかな問題があります.これらの情報を減らすことができれば、データ構造を理解する必要が少なくなるため、このプロセスは簡単になります.
根本的な問題は、ヘッダファイルに多くの情報が入っていることです.主な貢献者はデータ構造声明です.プロジェクトを開始すると、ヘッダーファイルにいくつかの声明を入れて、プロジェクトが進行中であればあるほど、多くなります.あなたが反応したらもうしびれています.あなたの実装ファイルにはデータ構造のすべてがあります(The majority of your source files have knowledge of the data structures and directly reference elements from the structures.)
複数のデータ構造を変更する場合を考慮します.すべての場所を再コンパイルしなければなりません(Making changes in an environment where many data structures directly refer to other data structures becomes, at best, a headache. Consider what happens when you change a data structure. This change forces you to recompile every source file that directly, or more importantly indirectly, refers to the changed data structure. This happens when a source file refers to a data structure that refers to a data structure that refers to the changed data structure. A change to the data structure may force you to modify some code, possibly in multiple source files. )
第4節ではクラスを用いてこの問題を解決する
1.3テクニックは規模に関係なく
例えば、プログラマーjoeはルールを制定し、すべてのデータ声明をヘッダファイルに入れなければならない.これにより、すべての実装ファイルが直接アクセスでき、速度の優位性を勝ち取ったふりをし、彼の製品もより高度になる.
これは、彼の製品の第1版で役立つ可能性があります.彼の製品の規模がますます大きくなり、臨界点に達すると、大量の公共データ声明が管理できなくなります.彼の仕事は困っている.この戦略は小規模なプロジェクトでよく働いていますが、大規模なプロジェクトでは残念なことに失敗しました.優秀な小さな種目はいずれ大きな種目になるだろう.
あなたのプログラミング方法は融通がきくべきで、大小のプロジェクトでも通じることを理解しなければなりません.
1.4グローバル変数が多すぎる
グローバル変数はできるだけ避けるべきです.この用法は大きな応用に限界がある.大きな応用がますます大きくなると、グローバル変数の数がますます多くなります.あなたが反応したら、あなたのグローバル変数はもうあなたが管理できないほど多くなりました.
グローバル変数を使用する場合は、なぜグローバル変数に直接アクセスする必要があるのかを考えてみましょう.モジュール関数呼び出しを変数に置くと効果は同じではありません(Would a function call to the module where the variable is defined work just as well?)ほとんどの場合、代替できます.グローバル変数が変更された場合は、自分のグローバル変数の影響を聞く必要があります.関数呼び出しに置き換えられた場合は、関数処理に問題を渡します.
一部のグローバル変数は影響が大きくなく、プロジェクトがどんなに大きくても、グローバル変数は多すぎるべきではありません.
1.5 debuggerによる
デブガーに頼りすぎてバグを捕まえるのではなく、自分が前に設定したルールやテクニックを使ってください.
1.6問題ではなく現象を解決する
例えばあなたはあなたのコードの中で1つのバグに出会って、//この段は何の意味もなく翻訳しませんでした
1つの高度な例はメモリの漏洩で、多くの場合、メモリの漏洩は直接問題を引き起こすことはありません.メモリが枯渇するまで、メモリが枯渇した結果、メモリが枯渇したコードを見つけて、このメモリを回収しました.bugはfixedに見えますが、ありません.
隠したメモリ漏洩の問題はまだあなたのコードにあります.メモリの漏洩を追跡するのに時間を費やすのではなく、メモリが漏洩した場所を教えてくれるスタック管理モジュールが必要です.この問題を徹底的に解決すると、スタック管理モジュールは具体的な詳細を教えてくれ、どこで漏れが発生したのかを教えてくれます.第五節ではこの問題をよく討論する.
1.7保守不可コード
通常、他の人が書いたコードを維持したり、バグを修正したり、新しい機能を追加したりすることに遭遇します.私はあなたがどう思っているのか分かりません.私にとってこれは楽しい体験ではありません.通常、コードは理解しにくいので、コードの流れが何なのかを考えるのに時間がかかります.
とにかく最後に誰かがあなたのコードを見ていることがわかるので、できるだけ曖昧に書かないでください.注釈がはっきりしていない限り//やはり作者もそう思っています.
1.8マイクロソフトの内蔵デバッガを使用しない
詳しく言わない
1.9まとめ The first step in writing bug-free code is to understand why bugs exist. The second step is to take action. That is what this book is all about. Programming methodologies that are developed to prevent and detect bugs must work equally well for both small and large programming projects. A technique that helps eliminate data structure declarations from include files needs to be found. Doing so will allow programmers to come up to speed on an existing project much quicker. Global variables that are known to more than one source file should be avoided. Global variables make it hard to maintain a project. Debuggers should be used only as a last resort. Having to resort to a debugger means that your programming methodologies used to detect bugs have failed. When you fix a bug, make sure you are really fixing the underlying cause of the bug and not just the symptom of the bug. Ask yourself how many times you have fixed the same type of bug. Strive to write code that is straightforward and easily understandable by others. Avoid writing code that pulls a lot of tricks. Finally, make sure that you use the Windows debug kernel all the time. It contains extra error checking that can automatically detect certain types of bugs that go undetected in the retail release of Windows
この翻訳は参考にしてください/ブログは数を集めます/多数の翻訳は意訳で、持っていない部分は英語の原文をプラスします
Chapter 1:Understand Why Bugs Exist/なぜバグがあるのか理解
ソフトウェア開発の反復の中でどうしていつもバグがこっそり入ってくるのですか?なぜbugが存在するのかを理解するのに時間がかかるのはbug-freeコードを書く最初のステップです.第2歩は、問題/検出問題を減らすための行動策定戦略をとることです.さらに重要なのは、チーム全体にこれらの新しい戦略を理解させることです.
筆者の親友は特別な会社で働いており、彼が書いたコードとモジュールに対してランタイムパラメータチェック(run-time parameter validation)を使用します.これは良いアイデアですが、このような強制的なやり方は他のプログラマーをあまり望んでいないかもしれません.ある日、友达は古いコードを少し修正して、パラメータチェックを加えました.彼はコードをテストしてコードライブラリに転送し、数週間後にこのコードが古いコード(1年前の)を呼び出すとパラメータエラーが表示されます.しかし、一部のプログラマーはこのパラメータをチェックアウトしたいと思っています.彼らはエラーログの印刷があると思っています.古いコードに問題があるわけではありません.新しいパラメータの検証が間違っているに違いありません.
これは極端な例ですが、1つのプログラミングプロジェクトでチーム全員にこの戦略の実施を理解させなければならないことを説明するのに十分です.
1.1小項目vs.大項目
hex dumpツール(DUMPと呼ばれる)を書く必要がある場合は、コマンドラインに表示したいファイルの名前をパラメータとして受信する必要があります.バグのないコードを書くことができますか?もしかすると、このプロジェクトは小さいので、定義がよくて隔離してもインタラクションがありません.
だから、ALPHAというプロジェクトを書くように要求されたら、あなたの会社は他の会社が持っているプロジェクトに集中します.このプロジェクトには数百行以上のコードが必要で、すでに10人のプログラマーがこのプロジェクトで働いています.納期はもうすぐです.会社にはあなたの知恵が必要です.すぐにこのチームに飛び込み、新しいコードを書き、バグを導入しないと思いますか.私にはできません.間違いを捕まえる方法がなければ、どんな初心者でもバグを導入します.
あなたが今処理している最大のプロジェクトを考えてみてください.どれだけのヘッダーファイルがあり、ヘッダーファイルには何がありますか.ソースファイルはいくつありますか.そして、中には何がありますか.DUMPという小さなツールを処理するのは問題ありませんが、なぜこの大きなプロジェクトを処理するのがこんなに難しいのですか?どうして大きなプロジェクトは10個100個の小さなプロジェクトほど簡単ではありませんか.
， bug
私たちはあなたの小さなプロジェクトを研究します.いくつかのヘッダファイルと実装ファイルから構成され、ヘッダファイルには関数のプロトタイプ、データ構造宣言、マクロ定義、typedef定義などがあり、ファイルが十分に少ないため、処理することができます.今、それを10に100を乗じると、突然このプロジェクトは管理できなくなります.
あなたのヘッダーファイルには管理するものがたくさんあります.このプロジェクトはサポートが必要です.人数を増やしてこのプロジェクトを処理すると、より速く完成しますが、これは問題を深刻化させるだけです.今、より多くの人がヘッダーファイルに情報を追加し、他の人が理解する必要があります.これはすべての大きなプロジェクトが悪循環に陥っているからです.
1.2ヘッダファイルにデータ構造が多すぎる
大きなプロジェクトでは、データ構造を熟知するのに時間がかかるという明らかな問題があります.これらの情報を減らすことができれば、データ構造を理解する必要が少なくなるため、このプロセスは簡単になります.
根本的な問題は、ヘッダファイルに多くの情報が入っていることです.主な貢献者はデータ構造声明です.プロジェクトを開始すると、ヘッダーファイルにいくつかの声明を入れて、プロジェクトが進行中であればあるほど、多くなります.あなたが反応したらもうしびれています.あなたの実装ファイルにはデータ構造のすべてがあります(The majority of your source files have knowledge of the data structures and directly reference elements from the structures.)
複数のデータ構造を変更する場合を考慮します.すべての場所を再コンパイルしなければなりません(Making changes in an environment where many data structures directly refer to other data structures becomes, at best, a headache. Consider what happens when you change a data structure. This change forces you to recompile every source file that directly, or more importantly indirectly, refers to the changed data structure. This happens when a source file refers to a data structure that refers to a data structure that refers to the changed data structure. A change to the data structure may force you to modify some code, possibly in multiple source files. )
第4節ではクラスを用いてこの問題を解決する
1.3テクニックは規模に関係なく
，
例えば、プログラマーjoeはルールを制定し、すべてのデータ声明をヘッダファイルに入れなければならない.これにより、すべての実装ファイルが直接アクセスでき、速度の優位性を勝ち取ったふりをし、彼の製品もより高度になる.
これは、彼の製品の第1版で役立つ可能性があります.彼の製品の規模がますます大きくなり、臨界点に達すると、大量の公共データ声明が管理できなくなります.彼の仕事は困っている.この戦略は小規模なプロジェクトでよく働いていますが、大規模なプロジェクトでは残念なことに失敗しました.優秀な小さな種目はいずれ大きな種目になるだろう.
あなたのプログラミング方法は融通がきくべきで、大小のプロジェクトでも通じることを理解しなければなりません.
1.4グローバル変数が多すぎる
グローバル変数はできるだけ避けるべきです.この用法は大きな応用に限界がある.大きな応用がますます大きくなると、グローバル変数の数がますます多くなります.あなたが反応したら、あなたのグローバル変数はもうあなたが管理できないほど多くなりました.
グローバル変数を使用する場合は、なぜグローバル変数に直接アクセスする必要があるのかを考えてみましょう.モジュール関数呼び出しを変数に置くと効果は同じではありません(Would a function call to the module where the variable is defined work just as well?)ほとんどの場合、代替できます.グローバル変数が変更された場合は、自分のグローバル変数の影響を聞く必要があります.関数呼び出しに置き換えられた場合は、関数処理に問題を渡します.
一部のグローバル変数は影響が大きくなく、プロジェクトがどんなに大きくても、グローバル変数は多すぎるべきではありません.
1.5 debuggerによる
bug debugger , ， ， bug-free 。
デブガーに頼りすぎてバグを捕まえるのではなく、自分が前に設定したルールやテクニックを使ってください.
1.6問題ではなく現象を解決する
例えばあなたはあなたのコードの中で1つのバグに出会って、//この段は何の意味もなく翻訳しませんでした
bug bug bug ，
1つの高度な例はメモリの漏洩で、多くの場合、メモリの漏洩は直接問題を引き起こすことはありません.メモリが枯渇するまで、メモリが枯渇した結果、メモリが枯渇したコードを見つけて、このメモリを回収しました.bugはfixedに見えますが、ありません.
隠したメモリ漏洩の問題はまだあなたのコードにあります.メモリの漏洩を追跡するのに時間を費やすのではなく、メモリが漏洩した場所を教えてくれるスタック管理モジュールが必要です.この問題を徹底的に解決すると、スタック管理モジュールは具体的な詳細を教えてくれ、どこで漏れが発生したのかを教えてくれます.第五節ではこの問題をよく討論する.
1.7保守不可コード
通常、他の人が書いたコードを維持したり、バグを修正したり、新しい機能を追加したりすることに遭遇します.私はあなたがどう思っているのか分かりません.私にとってこれは楽しい体験ではありません.通常、コードは理解しにくいので、コードの流れが何なのかを考えるのに時間がかかります.
// ，
とにかく最後に誰かがあなたのコードを見ていることがわかるので、できるだけ曖昧に書かないでください.注釈がはっきりしていない限り//やはり作者もそう思っています.
1.8マイクロソフトの内蔵デバッガを使用しない
詳しく言わない
1.9まとめ