コードを改善する方法を検討する小さな電子書籍を書きました。 この本はC / C ++プログラマーに焦点を当てていますが、他の言語を使用する開発者にとって興味深いものです。 この本の形式は私の最愛のHabrには向いていませんが、フィードバックを受け取り、記事で表現されている考えを議論することに興味があります。 したがって、私はここに発表のみを掲載することにし、記事自体はここにあります 。 そして、議論のためにコメントをお願いします。
このヒント集をお楽しみください。 もちろん、プログラムを誤って記述するすべての方法について警告することは不可能であり、これは意味がありません。 私の目標は、プログラマーに警告し、彼に危険を感じることでした。 おそらく、プログラマーが理解できない何かに再び遭遇したとき、彼は私の指示を覚えていて、急いで行きません。 文書を数分間調べたり、よりシンプルで明快なコードを書いたりすることで、数年間ユーザーや同僚の生活を害するような隠れたエラーの導入を避けることができます。
私が検討している42のトピックは次のとおりです。
- コンパイラを想定しないでください
- 0より大きい、これは1ではありません
- 一度コピーして、数回チェックする
- 演算子を恐れますか?:そして括弧で囲みます
- 利用可能なコード検証ツールを使用する
- ポインターが整数型に明示的にキャストされているすべての場所を確認します
- ループ内でalloca()関数を呼び出さないでください
- デストラクタの例外は危険であることを忘れないでください
- 終端のゼロを示すには、リテラル「\ 0」を使用します
- #ifdefを使用するときにフェードしないようにしてください
- コードの行を貪欲にしないでください
- Copy-Pasteを練習するときは、作業の最後に集中してください。
- 同じタイプのコードを「テーブル」に揃える
- 覚えておいてください:常に十分なコンパイラと良いコーディングスタイル
- 可能であれば、enumクラスの使用を開始します。
- 「できることを見て」-プログラミングでは受け入れられない
- 特殊な機能を使用して、メモリ内のプライベートデータを消去する
- ある言語で作業したときに得た知識は、別の言語に常に適用できるとは限りません
- あるコンストラクタを別のコンストラクタから適切に呼び出す方法
- ファイルの終わり(EOF)チェックでは不十分な場合がある
- ファイルの終わり(EOF)フラグを正しくチェックする
- #pragma warningを使用しないでください(デフォルト:X)
- 文字列リテラルの長さを自動的に計算する
- オーバーライドおよび最終IDは新しい友達になるはずです
- 「this」とnullptrを比較しない
- 陰湿なVARIANT_BOOL
- 陰湿なBSTR文字列
- 通常の関数を作成できるマクロを作成しないでください
- イテレータには、接尾辞(i ++)の代わりに接頭辞インクリメント演算子(++ i)を使用します
- Visual C ++およびwprintf()関数
- CおよびC ++では、配列は値で渡されません
- 恐怖のプリント
- NULLポインターを逆参照しない
- 未定義の動作は、思っているよりも近い
- 列挙に新しい定数を追加し、switchステートメントを修正することを忘れないでください
- コンピューターでマジックイベントが発生した場合は、メモリを確認してください
- do {...} while(...)内のcontinueステートメントを恐れる
- 今日から、NULLではなくnullptrを使用します
- 誤ったコードが時々機能する理由
- 静的コード分析を実装する
- プロジェクトへの新しいライブラリの追加に抵抗する
- 関数に「空」という名前を付けないでください
そのため、記事へのリンク: http : //www.viva64.com/en/b/0391/
英語: http : //www.viva64.com/en/b/0391/
Habroeffectが誤って発生する可能性があると予測しているため、事前に確認したいと思います。 そのため、Yandex DiskにPDF形式で投稿します。
ロシア語: https : //yadi.sk/i/LKkWupFjr5WzR
英語: https : //yadi.sk/i/pBZqebxsr5Wyg
PS私は本のテキストを他のサイトに特に配置しません。 非常に多くの人々がテキストの欠点を報告しており、テキストが複数の場所で公開されている場合、私は修正を行うために苦しみます。 テキストが安定したら、別の形式で別の場所に投稿します。 それまでの間、ご理解のうえお取り扱いください。 そして別のリクエスト。 コメントではなく、電子メール(karpov [@] viva64.com)で気づいた失策について書いてください。