良いジョークのような良いコード-説明は必要ありません。
コードがシンプルで明快であれば、ほとんどの場合、コメントやドキュメントは必要ありません。
優れたコードは、優れたステレオホルダーとカップホルダーを備えた車のようなもので、問題なく限界までプッシュできます。 破損した場合、メカニックは従来のツールを使用して短時間で修正できます。
悪いコードは、時速120 kmに到達することを約束する車のようなものですが、カセットテープのみを受け入れるステレオを備えており、カップホルダーには底が傾斜しています。 ミラーをセットアップしようとするたびに、車は炎の中で爆発し、独自のツールを使用して組立ラインで組み立てた特定の人が修理する必要があります。
良いコードはよく書かれたチュートリアルのようなものです
- シンプルで明確
- 便利に章に分かれており、各章は明確に定義されたトピックに当てられています。
悪いコードは、ひどく書かれたチュートリアルのようなものです
- すべての章は相互に参照しており、何が危機にatしているかは明確ではありません
- まったく同じ話が何度も何度も語られ、理由もなく
- 著者は規則にいくつかの例外を述べているが、しばしば矛盾している
- 吸血鬼が突然現れます！ 彼は太陽の下で輝く
良いコードを書きたい場合、これは覚えておくことが重要です：
- 可視性-あなたとあなたのコードを調べることにした人のために
- サポート能力-コードは簡単に変更可能でなければなりません
- シンプル-理由もなくすべてを複雑にしない
- 効率-コードは可能な限り高速に動作するはずです
- わかりやすさ-コードがシンプルで理解しやすい場合、ほとんどの場合、コメントは不要です。 そのようなプロパティとメソッドの名前を選択して、彼が何をしているかがすぐにわかるようにします。
- 摂動と驚くべき1分あたりの感嘆符の低い相関-他の開発者がコードを読んで「WTF？！」と言う頻度を最小限に抑えます。
コード品質チェック
コードをまだ見たことのない別のプログラマーに見せ、各モジュールが何をするのかを説明してもらい、注意深く耳を傾けます。
中断し、独自の方法で説明したいほど、コードが悪化する可能性が高くなります。
落ち着いて静かに聞くことができ、あなたの隣の人がすべてを説明し、質問をしないなら、おそらくあなたのコードは良いでしょう。
良いコードの兆候：
- 彼はスマートに見えますが、難解ではありません。
- 週末の後、コードの記述に戻り、記述内容を再考せずにすぐに仕事に取りかかることができます
- アルゴリズムは速度と読みやすさの点で最適です。
- クラス、変数、関数には名前が付けられているため、必要な理由を理解するために脳に負担をかける必要がありません
- 各クラスは、明確に定義された1つの目的のためのものであり、他のクラスとは別個のものです。
- あなたの方法は短い-理想的には50行より短く、そして確かに100行以下
- メソッドは1つのタスク用です。
- メソッドの名前は、メソッドの動作を一意に決定するため、このメソッド内のコードを調べる必要はありません。
- 戻っていくつかの機能を追加/変更する必要がある場合、これにより問題は発生しません。
- try / catchブロックはできるだけ小さくします。
- 単体テストは簡単に記述でき、簡単です。
良いコードはモジュラーです
プロジェクトには、内部、中、外部の3つのレイヤーがあるとします。
内側の層は、中間層または外側の層について何も知らないはずです。 中間層は、外側の層について何も知らないはずです。
したがって、内部コード層を個別にテストできます。
詳細については、 この記事をご覧ください （ 翻訳者リンク ）
「良いコードは私たちの最高のドキュメントです」-Steve McConnell