他の人のコードを読むことにどれほどの頻度で驚嘆し、「主よ、めちゃくちゃだ！」 ほとんどの場合、かなり頻繁に。 また、コードを読むときに誰も考えていないことを確信できますか？ 言い換えれば、あなたのコードについてどの程度自信がありますか？ 純粋なコードが何を意味するのかを完全に理解している場合にのみ確信が持てます。
純粋なコードに正確な定義を与えることは困難であり、最も多くの場合、何人のプログラマーが非常に多くの定義であるかです。 ただし、一部の原則は非常に普遍的です。 最も関連性が高く、以下に説明するものを9つ収集しました。
1.悪いコードはやり過ぎ、きれいなコードに焦点を当てる
すべてのクラス、メソッド、およびその他のエンティティは、歪めないままにしておく必要があります。 彼女は唯一の義務の原則に従わなければなりません。 要するに、私たちはこれを言うことができます：あなたがクラスを変える理由について考えるならば、あなたは2つ以上の正当な理由を思い付くことができません。
しかし、定義をクラスに限定しません。 最後の記事で、 ラルフウェストファルは、単一義務の原則のより広い定義を紹介しました。
特定の抽象化レベルの機能ユニットは、システムの要件の1つの側面を担当する必要があります。 要件の側面は、他の側面とは独立して変更できる要件の機能またはプロパティです。
もっと知りたい場合は、彼の記事を読むことをお勧めします。
2.コードを記述した言語は、この問題を解決するために作成されたように見えるはずです。
プログラムを単純にするのは言語ではなく、言語を単純に見せるプログラマーです。
（ロバートC.マーティンからの引用）
これは、ハックを使用する必要がないことを意味します。そのため、通常、コードと言語は厄介に見えます。 何かがハックまたはパッチでしかできないと考えている場合、これは通常、適切でクリーンなソリューションを見つけるために十分な時間を費やしていないことを意味します。
3.冗長性は不要
コードはDRYルールに従う必要があります（繰り返してはいけません-繰り返してはいけません） 。 その場合、システムの要素を変更しても、論理的に無関係な他の要素を変更する必要はありません。
4.コードを読むのはいいはずです
コードを読むとき、「ハリー・ポッター」を読んでいるように感じるはずです（はい、私は行き過ぎです）。 開発者は何時間も費やさずに簡単に読むことができるように書かれているように感じられるはずです。
これを行うには、 KISS （Keep It Simple、Stupid！）とYAGNI （You A't Gonna Need It It- You't need it）の原則に従うようにしてください。 KISSの原則では、ほとんどのシステムはシンプルに保ち、複雑さを増やさない場合に最適に機能すると述べています。
つまり、シンプルさは設計の目標であり、不必要な複雑化を避ける必要があります。 YAGNIは、ソフトウェアを機能させる最も単純なことに集中するように動機付けるプラクティスです。
5.別の開発者がコードを簡単に拡張できます。
あなた自身のために、またはさらに悪いことに、コンパイラのためにコードを書くことはありません。 他の開発者向けにコードを記述します。 利己的ではありません-人について考えてください。 サポートが不十分で拡張性の低いコードを発行して、他の開発者を苦しめないでください。 さらに、数か月後には、この他の開発者になることができます。
6.依存関係を最小限に抑える必要がある
依存関係が多いほど、将来コードを維持および変更することが難しくなります。 いつでも（.NETの場合、およそ） NDEPENDを使用して依存関係を最小限に抑えることができます。 コード依存関係の潜在的なエラーをチェックします。
7.少ないほど良い
コードは最小限でなければなりません。 クラスとモジュールは短く、理想的には数行のコードである必要があります。 コードは適切に分離する必要があります（クラス内を含む）。 コードを共有すればするほど、読みやすくなります。 この原則は、ポイント4に良い影響を及ぼします。他のプログラマーが理解しやすくなります。
8.ユニットおよび受け入れテストが必要
テストを作成しない場合、コードが要件を満たしているかどうかを確認するにはどうすればよいですか？ すべてが壊れるのではないかと心配せずに、どうすればそれを維持および拡張できますか？ テストなしのコードは、単純ではありません。 単体テストの原則について詳しく知りたい場合は、同僚の1人が書いた非常に優れた記事「 単体テストの3つの柱 」を読むことをお勧めします。
9.コードは表現力豊かでなければなりません
コードの表現力は、意味のある名前を使用することを意味します。 これらの名前は意図を表現する必要があります。 混同しないでください。 それらは区別可能でなければなりません。 表現力はコードを文書化し、別個の文書の必要性を減らします。 自己文書化コードのトピックについて詳しく知りたい場合は、 この記事を読むことをお勧めします。
では、クリーンコードとは何ですか？
一般に、最後の1つの品質は、上記のすべての結果と呼ばれます。
純粋なコードは、気にしない人のために書かれています。
マイケル・フェザーズからの引用。
コードをアートとして扱い、すべての詳細に注意を払う人々によって書かれています。
クリーンコードのトピックは非常に複雑であり、この記事で説明されている内容を超えています。 したがって、純粋なコードには他の特性があると思われる場合は、コメントで共有してください。