パートI：処理コードの詳細（コード面）
コードの詳細を処理し、確認し、以下のいくつかの方向に分かれています。
- グッド防衛、コードの堅牢性を考慮してください。
- 良いスタイル。慎重なレイアウト。
- ファイルだけでなく、様々な部品や機能のための良い名前。
- 良いコメント。
- エラー処理、エラー処理が発生することがあります。クラッシュしないように保証します。
- 論理的、理解しやすいです。
1.防御
守備インセンティブ：
- 悪意のあるユーザー
- 使用のクライアントのエラー
- 動作環境不完全
- 外部の実行時の問題
あなたはローカル変数の機能を使用することができた場合は、グローバル変数を使用しないでください。あなたは、可変ループ本体を使用することができた場合は、関数レベルの変数を使用しないでください。
防衛エッセンス：
- 適切なスタイルと仕様を使用。
- 論理ではなく、シンプル。
- 適切な警告レベルを開きます。
- 静的リントチェッカーを使用します。
- 適切なプロセスの戻り値を確認してください。
- そして、ログレベルの使用の合理化。
- 慎重な型変換。
- 適切な制約、配列境界チェック、ポインタ
Q＆A：
- 各バグ修正のためのより良いユニットテストを行っています。
2.慎重なレイアウト
- スタイルを調整し、タブの幅を調整します。
良い名前から3
名前付きオブジェクトの必要性は、以下のとおりです。
- 変数
- 機能
- タイプ
- パッケージ名
- マクロ
- ファイル名
- 良い名前から名前への鍵は、名前付きオブジェクトを理解することです。
- 命名すると、かなりの明確かつ簡潔な焦点よりますが、ループカウンタとして、あなたは短い変数を使うことができます。
- 関数を命名すると機能がプロセスであるので、それは動詞、テーブル名、いくつかの論理機能で始めるのがベストです。
- マクロ名、すべて大文字、およびプロジェクトで始まるとき。
- ファイル名の関数として記述ファイル、論理ファイルを複数に分割することができます。
- ネーミングは一貫しています。
- 名前は、その範囲を決定するときは、そう明確な記述を持っています。
自明4.書き込みコードのスキル
- あなたは、メンテナンスのドキュメント自体が大きなチャレンジ、一定の繰り返しで、特にコードで、大規模なプロジェクトのためとして、外部ドキュメントをサポートするためのコードを記述する必要はありません。
- コメントにそれを使用するのは良いアイデアです？いいえ、コメントではなく、良い自己説明点在します。
- 良いコードブックとしてよく組織。
- プリアンブルコードは、ファイルヘッダ、コンテンツ記述ファイル、機能、プロジェクト属する対応するコメント。
- （現代のソフトウェアは、IDEを使用することができます）ファイル関数、クラス、変数に対応するリストディレクトリ
- コード部分に対応する部分は、1つのファイルをお勧めしません、ロジックの大部分を表す、「部分」に複数のソースファイルをパッケージ化することが可能であり、大きすぎます。
- 章では、彼は論理関数の機能的に独立した完全なセットで、一つのソースファイルに対応しています。
- 段落コードは、上の変数など、組織の各機能に対応します。
- 声明では、各ステートメントに対応します。
- 簡単なコードを書くために良いスタイルを使用します
- エラーを処理するコードまたは正しい分岐による通常のフローが前面に常にしてみましょう。
- 過度のネストを避けてください。
- 慎重に理解することは容易ではない場合は、コメントを明確にする必要があり、コードを最適化しました。
- 意味のある名前を選択します
- すべての変数、関数、ファイル名、タイプは、正確な意味を持っている必要があります。
- 分解アトミック機能
- 関数名を観察操作する関数は、関数の機能を知ることができるようになります。
- 短いそれを保管してください。
- 適切な型を使用します
- 変数が負の値が含まれていないような、そして直接使用UINT
- 変数を変更できない場合は、constの修正によって
- 重要なコードをハイライト
- 重要でない情報やコードを隠します
- ネストされた条件文の数を制限します。処理条件は、ネスト隠された重要なことは避けてください。
- 関連情報のグループ化
- 行く、関連情報をグループ化、言語のメカニズムを使用することにより、パッケージが（c）であり、ファイルです。
- 適切にエラーを処理
- それぞれの層が自分のエラーを処理、無意味なエラーを返しません。エラーは、ディスク・アクセス・コードで発生した場合、ディスクエラーの取り扱い上のこの層は、その後、エラーがトップが開いているファイルの処理エラーであってもよいし、アップスローされます。
- 自己記述のためのコード、文書は何が必要ですか？
- これは、システム全体の説明や文書のロールが必要です
- システム設計文書の概要ドキュメントと構造
- テスト仕様
5.適切なコメントを書きます
- あなただけではあまりにも遠く、十分な注意事項を記述する必要があります。
- 複雑な場所のため、コードは自明であるならば、何が行われているようそうすることが、より重要である理由を説明するために、非常に明確に扱ってきました。
- それを書き換え、不正なコードを文書化しないでください。あなたは何の被害機能は後に書き換えていないことを確認するために、ユニットテストを使用することができます。
- コメントは、物事が変更されている記載されていない、と過去に事を教えていない、現在に生きるべき何をするかです。
- あなたは、コードを変更すると、周りのすべてのコメントを維持します。
6.エラー処理
- 3種類に分類集計を原因：
- ユーザエラー、ユーザエラー、または入力操作
- プログラマーのエラー
- 不測の事態
- エラーコードを制御するために、我々は実行する必要があります。
- エラーが発生したときにエラーをしました
- すべての可能なエラーレポートを検出
- 適切にエラーを処理
- 私たちは、誤り伝播を処理することはできません
- エラー報告機構
- それは良いアイデア中止されていないが、このようなエラーが発生報告しないでください。
- 戻り値を使用します
- この方法を使用していない、などのerrno C言語のように間違った状態変数を使用して、
- 異常な
- 信号を使用します
- 処理エラー
- エラーを処理する場合
- 可能な限り早期に（できるだけ遅く過程で）治療は、何も良いか悪いか、妥協はありません
- エラー後のクリーンアップの方法