C ++でバグを避ける10の方法 - ダミー

最初にC ++プログラムを実際に書くのに費やす時間より多くの時間を費やしてバグを取り除くことは残念です。ここでの提案は、プログラミングをより楽しいものにするために、プログラムに導入するエラーの数を最小限に抑えるのに役立ちます。

すべての警告とエラーメッセージを有効にする

C ++の構文では、多くのエラーチェックが可能です。コンパイラが解読できない構造に遭遇すると、メッセージを出力するだけでは選択肢がありません。ソースコードとバックアップを同期しようとしますが（時には成功しない場合もあります）、実行可能ファイルは生成されません。これにより、プログラマーはすべてのエラーメッセージを修正するようになります。

<！しかし、C ++がわかる構造体があるにもかかわらず、構造体が怪しげになると、C ++は警告メッセージを生成します。 C ++はあなたが望むものを理解していると確信しているので、実行可能ファイルを作成して、好きなときに警告を無視することができます。実際に、気にしたくない場合は、警告を無効にすることができます。

警告を無効にするか無視することは、非常に悪い考えです。それはあなたを悩ませるので、あなたの車のダッシュボードにある "チェックエンジン"のライトを抜くようなものです。問題を無視してもそれは消えない。

<！ C ++コードを明快で一貫したスタイルで書くことは、プログラムの可読性を向上させるだけでなく、コーディングミスを減らすことにもつながります。このやや驚くべき事態は、私たちの脳は限られた量の計算能力しか持たないという事実に起因します。

あなたが慣れ親しんだスタイルに従っているきれいできちんとしたコードを読むと、C ++ステートメントのシンタックスをパースする脳力をほとんど消費しません。これにより、プログラムが何をやろうとしているのかを解読するために、より多くの脳のCPU能力が残されます。

<！

クラス名、オブジェクト名、および関数名を区別する

クラス、関数、またはオブジェクトがどのような目的で使用されているかを理解する

C ++コードからプリプロセッサシンボルを区別する（つまり、#defineオブジェクトが目立つようにする）

同じレベルのC ++コードのブロックを識別する（これは一貫したインデントの結果である）

さらに、各モジュールの関数またはクラス、作成者、日付、バージョン、および変更履歴に関する情報を提供するモジュールヘッダーの標準形式を確立する必要があります。
単一のプロジェクトに関わるすべてのプログラマーは、同じコーディングスタイルを使用する必要があります。さまざまなコーディングスタイルのパッチワークで書かれたプログラムは混乱しており、プロフェッショナルではありません。
コードの記述中にコメントを書く
すべてのコードが動作するまで待ってからコメントを追加するだけでなく、コードを記述しているときにコメントを書くとエラーを回避できます。

コメントを定式化することで、あなたがしようとしていることを考慮する必要があります。短いコメントは、後で読むときと書くときの両方で啓発されます。あたかも他の有能なプログラマーと話しているかのようにコメントを書く。

デバッガ内のすべてのパスを少なくとも1回シングルステップ

プログラマは、プログラムが何をしているのかを理解する必要があります。プログラムが期待値を出力するだけでは不十分です。あなたはあなたのプログラムがやっていること全てを理解する必要があります。フードの中で起こっていることは、プログラムをシングルステッピング

するよりも、デバッガ（Code：：Blocksに付属しているようなもの）を使って段階的に実行しているよりも、良い感じはありません。それ以外にも、プログラムをデバッグするときには、プログラムが実行されるときに起きるかもしれないいくつかの奇妙な動作を理解するために、素材が必要です。サービスに入るたびに、各機能を1ステップずつ進める以上に、その材料をあなたに提供するものはありません。最後に、関数が終了してプログラムに追加する準備ができたら、すべての論理パスを少なくとも1回は移動させる必要があります。バグは、関数の残りの部分と一緒にポットに投げ込まれた後ではなく、それ自身で関数を調べると、はるかに簡単に見つけられます。新しいプログラミングの課題にあなたの注意が向けられています。

可視性を制限する

クラス内部の可視性を外部に限定することは、オブジェクト指向プログラミングの基礎です。クラスは内部状態を担当する必要があります。何かがクラスに陥った場合、クラスのプログラマーの責任です。アプリケーションプログラマは、問題の解決を心配する必要があります。

具体的には、可視性が限られているということは、データメンバがクラス外にアクセスできないようにすることです。つまり、保護されているとマークする必要があります。さらに、アプリケーションソフトウェアが知る必要がないメンバー機能には、保護されているとマークする必要があります。仕事を遂行するために必要以上にクラス内部を公開しないでください。ヒープメモリの追跡ヒープメモリの損失トラックは、現場にリリースされたプログラムの致命的なエラーの最も一般的な原因です。同時に、追跡して削除するのが最も難しい問題です。（このクラスのエラーは検出して削除するのが非常に難しいので、購入したプログラムでは流行しています。）問題が発生する前に数時間プログラムを実行しなければならない場合があります。

一般的なルールとして、プログラマは常に同じレベルでヒープメモリを割り当て、解放する必要があります。メンバ関数MyClass:: create（）がヒープメモリのブロックを割り当てて呼び出し側に返す場合、ヒープに返すメンバMyClass:: release（）が存在するはずです。具体的には、MyClass:: create（）は、親関数がメモリを解放する必要はありません。

可能であれば、MyClassはそのようなメモリポインタを独自に追跡し、デストラクタでそれらを削除する必要があります。

ポインターを削除した後にポインタをゼロにします。

ポインターが有効でなくなった後にポインタをゼロにします。それらにnullptrの値を代入することによって行います。このアクションの理由は、経験の浅いほど明らかになります。ヒープに戻ってきたメモリブロックを引き続き使用できます。プログラムは99％の時間で正常に動作するため、ブロックが再割り当てされてプログラムが機能しないケースの1％を見つけることが非常に困難になります。

有効でなくなったポインタをヌルにして値を格納しようとすると（ヌル位置またはその近くに何も格納することはできません）、プログラムはすぐにクラッシュします。クラッシュすると音が悪くなりますが、問題が発生した場合はそうではありません。問題はそこにあります。それは生産に入れる前にそれを見つけるかどうかの問題に過ぎません。

例外を使用してエラーを処理する

C ++の例外メカニズムは、エラーを便利かつ効率的に処理するように設計されています。一般に、エラーフラグを返すのではなく、エラーインジケータをスローする必要があります。結果として得られるコードは、書き込み、読み込み、および保守が容易です。他にも、他のプログラマーも期待していて、失望したくないのではないでしょうか？

あなたの例外の使用を真のエラーに制限します。これがその関数の日常生活の一部である場合、 "did not work"インジケータを返す関数から例外をスローする必要はありません。

デストラクタを仮想宣言する