あなたのコードを維持することになった人があなたがどこに住んでいるかを知っている暴力的なサイコパスであるかのように、常にコードします。
Damian Conway、Perl 6の共同デザイナー
優れたプログラムコードは、一意性、有効性、保守性の少なくとも3つの属性によって定義されます。
一意性は主にコーディングスタイルです。 一意性は、プログラマーが選択する変数と関数の名前、コードのフォーマット方法、エラーの処理方法、およびコード構造の形成によって決まります。
効率的なコードは、効率的なアルゴリズムで構成されるコードです。 有効とは、壊れやすい、複雑である、または維持が難しいという意味ではありません。 コードの有効性は、言語の長所を利用し、同時にその弱点を回避することにより達成されます。
保守性は、コードが主に同行する人のために書かれていることです。 伴奏-記述されたコードの使いやすさ、変更時のエラーの可能性を最小限に抑えます。
コードの一意性
すべてのプログラマーは怠sometimesであり、時には良い意味で、時には普通のことです。 また、コードの各行を、適切なコードの基準に従って整理するのに十分な時間を与える人はほとんどいません。 特に、「このチェックを関数に設定するのが早ければ早いほど、家に帰る」ことになります。 したがって、1つのシンボル、1行の複数の式、および適用されたプログラミング言語で可能な他の多くのトリックによって名前が付けられた変数。
一方、既存のすべてのコード改善手法（およびこの記事も）は、プログラマー自身の作業を楽にすることを目的としています。 たとえば、コードを他のプログラマー（および作成後Nか月間）が理解できるようにするには、コーディングスタイルに従う必要があります。 使用する言語に提案されているスタイルのうち、K＆Rスタイルのコードの書式設定が推奨されるスタイルを選択することをお勧めします（K言語の本の著者であるKernighanとRitchieのイニシャルによる）。
アラートを無効にして、無能を隠さないでください。 エラーメッセージまたは警告を抑制する言語ツールは、言語の弱点です。 この方法により、アルゴリズムの潜在的なエラーがユーザーから隠され、コードが非常に脆弱になります。 リファクタリングするとき、そのようなアルゴリズムはほぼ確実に壊れます。
関数、変数、および定数の名前については、コメントなしでそれらの目的が明らかになるように、そのような名前を選択してください（コメントを書く必要がなくなるわけではありません）。 略語と略語のうち、一般に受け入れられているよく知られているもの、min、max、avg、sum、len、ctrl、src、msgなどのみを使用できます。 変数名の短い形式が見つからない場合は、そのままにしておきます。
名前付き定数を使用し、コードで裸の数字や文字列リテラルを避けます。 純粋な形式のコードで使用される各数値の目的がアルゴリズムにとって明確である場合でも、ある数値を別の数値に変更する必要がある場合、アルゴリズムを調整するとコードが破損する可能性があります。 名前付き定数を使用する場合、アルゴリズムコード自体に触れることなく、1か所で数値を変更するだけで十分です。 3.14、2.7、9.8、42などの既知の値に対しても例外を作成することはお勧めしません。
コード性能
多くのプログラマー（必ずしも専門分野で作業しているわけではない）は、1つの式に階乗を計算する機能を削減したことをお互いに自慢している学生のレベルのままです。 絶えず除算と乗算の代わりにビットシフトを使用することも良い考えではありません。 これらはまさに時期尚早の最適化の場合であり、非常に多くのことについて書かれ、語られています。
アルゴリズムの一部を最適化する前に、最適化が必要なのはそれであることを確認する必要があります。 プレフィックスのインクリメントのポストフィックスインクリメントを数十の場所で長時間変更し、数ナノ秒のプロセッサ時間を稼ぐことができますが、データベースクエリを最適化し、肉眼でも見えるパフォーマンスの向上を得ることをお勧めします。 アルゴリズムの弱いリンクを見つけるためには、アルゴリズムの各段階でコードの実行時間をプロファイリングして測定する必要があります。
車輪を再発明する前に、これがあなたの前に行われないことを確認する必要があります。 そして、自転車がないか、何らかの理由で「私には書かれていない」という理由を除いて、自転車があなたに合わない場合にのみ、実装を進めることができます。 サードパーティのライブラリを使用すると、独自のアルゴリズムに集中できます。 ライブラリの人気が高いほど、使用するコードの効率が上がり、ライブラリ内のエラーを検出する可能性が低くなります。 ライブラリインターフェイスが面倒であるか、統一されすぎている場合は、このライブラリのラッパーインターフェイスを記述して、コードが同じスタイルになるようにします。
アルゴリズムが長い計算の結果を頻繁に使用する場合、キャッシュの可能性を考慮することは理にかなっています。これらの計算の結果が変わらない場合、繰り返し計算を防ぐためにこれらの結果を保存します。
コードエスコート
コードに変更を加えると、常にそれを破る可能性があるため、アルゴリズムのすべての代替バージョンの中で、常に最も柔軟なものを使用してください。 たとえば、複数のelse-ifまたはスイッチの代わりに、ハッシュテーブルでキー検索を使用する方がはるかに便利です。 そのような場合、代替のリストに別の値を追加するには、検索アルゴリズム自体に触れることなくハッシュに別の値を追加するだけで十分です。
関数のライブラリを作成する場合は、最初にそのインターフェイスを設計し、まだ作成されていないライブラリの関数を使用するコードを作成します。 使いやすいですか？ そうでない場合、これはインターフェースを修正する機会であり、機能自体はまだ記述されていないため、リファクタリングする必要はありません。
彼らの実践の多くは、継承されたコードを常に扱っています。 また、誰かが長い間書いた関数を使用する必要があり、この関数のインターフェイスがずさんに設計されている場合、パラメータのセットが記憶されていないため、その名前だけがメモリに表示されることがあります。 このような場合、この関数が既に使用されているコード内の場所を探し、そこからコードに呼び出しをコピーする必要があります。 インターフェースの設計に十分な時間と労力を費やさないと、他の誰かがコードに同行するときが来たときに、同じことが自分の機能に起こる可能性があります。
コードの複雑さに関係なく、コメントが必要です。 少なくとも、各関数/メソッドのヘッダーで、何をするのか、どのパラメーターを取るのか、何を返すのか。 コメントがなければ、アルゴリズムの最も明らかな部分のみを残すことができます。各式にコメントすることは意味がありません。 アルゴリズムに詳細なコメントが必要かどうかを判断する最も簡単な方法は、それを理解するのにかかる秒数を把握することです。 5つ以上の場合-コメントが必要です。