デメテルの法則 オブジェクトの"メンバーのプロパティ/メソッド"を直接触らないようにする
ヴィルトの法則 「ソフトウェアは、ハードウェアが高速化するより急速に低速化する」
ブルックスの法則 「遅れているソフトウェアプロジェクトへの要員追加は、プロジェクトをさらに遅らせるだけだ」
コンウェイの法則
「システムを設計する組織は、自分たちの組織のコミュニケーション構造をそっくりそのままコピーした設計を生み出してしまう」
ホフスタッターの法則 「いつでも予測以上の時間がかかるものである — ホフスタッターの法則を計算に入れても。」
驚き最小の原則
インタフェースの2つの要素が互いに矛盾あるいは不明瞭だったときに、その動作としては人間のユーザやプログラマが最も自然に思える（驚きが少ない）ものを選択すべき
ボーイスカウトの規則 「モジュールをチェックインする際には、必ずチェックアウト時よりも美しくする」
DRY "Don't Repeat Yourself"の略。「同じことを繰り返すな」という意味。
SOLID
Single Responsibility Principle（単一責務の原則）
「クラスを変更する理由は１つでなければならない」
Open/closed principle（開放閉鎖の原則）
「クラスは拡張に対して開き、修正に対して閉じていなければならない」
Liskov substitution principle（リスコフの置換原則）
「派生型はその基本型と置換可能でなければならない」
Interface segregation principle（インターフェース分離の原則）
「クライアントが利用しないメソッドへの依存を強制してはならない」
Dependency inversion principle（依存性逆転の原則）
「上位のモジュールは下位のモジュールに依存してはならない。どちらのモジュールも「抽象」に依存すべきである。」
・プログラミングの進展をコードの行数で測るのは、飛行機建造の進展を重量で測るようなものだ。
ビル・ゲイツ
・今日のプログラミングは、馬鹿でも使える、より重大かつ高度なプログラムを構築する努力をしているソフトウェアエンジニアと、より重大かつ高度な馬鹿を生み出そうとする宇宙との間の競争である。今のところ、宇宙が勝っている。
Rich Cook
・あなたはプロジェクトを下のように行うことができる。
・時間通りに
・予算内に
・適切に
二つを選べ。
Unknown
・理論的には、理論と実践に違いはない。実践的には、ある。
Jan L. A. van de Snepscheut
・あなたのコードをメンテナンスすることになる人が、あなたの住所を知る強烈なサイコパスになりうるのを常に想定してコーディングしなさい。
Rick Osborne
・水の上を歩くのと、仕様書からソフトウェアを開発するのは簡単だ。もしもどちらも凍結しているならば。
Edward V Berard
・そもそも、デバッギングはコーディングよりも２倍難しい。従って、あなたが可能な限り賢くコードを書くとしたら、定義からして、あなたはそれをデバッグできるほど賢くない。
ブライアン カーニハン