この手の記事は、山ほどあるけど備忘録的にまとめておく

DRY

Don't Repeat Yourself.

頭文字を取って DRY と呼ぶ。
「あっちゃこっちゃに同じ処理を書き散らかさない」です。
ファイルを扱う処理は、一箇所にまとめる。DBアクセスする部分はあるところにまとめる。
同じ処理内容をあちらこちらにバラバラと散らかさない。
図書館でも、同じ分類のものは一箇所にまとまってますよね?

http://ja.wikipedia.org/wiki/Don't_repeat_yourself

OAOO

Once and Only Once

DRYと似ていますがもっと局所的な話で、「コードの重複の排除」です。
コピーアンドペーストの悪しき習慣を勇気をもって排除しましょう。
例えば、コピーして作成したプログラムにバグがあったらどうでしょう。
コピーした分だけ修正しなければいけませんよね?
どこに書かれている分からない、コピーアンドペーストされたバグコードはgrepして直すしか方法がありません。

YAGNI

You Aren't Going to Need It.

(今必要なことだけ行う)
先の事を考えて、前払い的に機能を増やし、実装を複雑化させる事は避ける。
むしろ無駄な機能があれば削りとり、今必要な機能だけのシンプルな実装に留めておく。
このことで後のイレギュラーな変更に対応しやすいようにする。
拡張可能性を残しつつ、必要最小限でということですかね。
良かれと思ってやったことは、たいてい余計なことです。
使いもしない関数や、メソッド、クラスをいたずらに増やさない。
いるかいらないかわからない、そんなときはいらない。

http://ja.wikipedia.org/wiki/YAGNI

KISSの原則

Keep it simple, stupid

直訳すると、シンプルにしとけ。クソッタレ。ということ。
美しいものは、みなシンプルです。
どんなに複雑なものでも、単純なものの組み合わせです。
単純でシンプルなものまで分解して、それを組み合わせましょう。
一つの関数、クラス、メソッドなどが数千行になってないですか?

http://ja.wikipedia.org/wiki/KISS%E3%81%AE%E5%8E%9F%E5%89%87

PIEの原則

Program Intently and Expressively

意図を明確にしろ。
レビューで、変数名、クラス名、メソッド名などをごちゃごちゃ言われるのは、その名前が何を意味しているか曖昧だからです。コードは人が読むことを前提としているため、人が読めなければ意味がない。
いつ、誰が読んでも理解できるコードを心がける。

これらは、プリンシプル オブ プログラミング にまとまってる。

May the Good Programing Life be with you.

Sign up for free and join this conversation.
Sign Up
If you already have a Qiita account log in.