Общие принципы программирования
Принцип DRY

    DRY («Don't Repeat Yourself»; с англ. – «Не повторяйся») – принцип разработки программного обеспечения, нацеленный на уменьшение сложности кода и снижения повторения информации. 

Принцип DRY формулируется как: «Каждая часть знания должна иметь единственное, непротиворечивое и авторитетное представление в рамках системы».

Сторонники принципа DRY стремятся обеспечить существование только одного способа выполнения кода -  объединять экземпляры повторящегося кода в единый блок, что окупается в долгосрочной перспективе, т. к. ускоряет время разработки. Когда принцип DRY применяется успешно, изменение единственного элемента системы не требует внесения изменений в другие, логически не связанные элементы. Те элементы, которые логически связаны, изменяются предсказуемо и единообразно. 

Нарушения принципа DRY называют WET — «Write Everything Twice» (Пиши всё дважды) или «We enjoy typing» (Нам нравится печатать).

Эмпирическое правило – как только вы начали писать код и заметили, что писали что-то похожее совсем недавно – срочно выделяйте участок кода в функцию/метод.
Принцип KISS

KISS (акроним для «Keep it simple, stupid» — «Делай проще, тупица»).

Принцип KISS утверждает, что большинство систем работают лучше всего, если они остаются простыми, а не усложняются. Поэтому в области проектирования простота должна быть одной из ключевых целей, и следует избегать ненужной сложности.

    Разбивайте задачи на подзадачи, которые не должны длиться более 4-12 часов написания кода
    Разбивайте задачу на более маленькие задачи, каждая задача должна решаться одним или парой классов
    Сохраняйте методы маленькими. Каждый метод должен состоять не более чем из 30-40 строк. Каждый метод должен решать одну маленькую задачу, а не множество случаев. Если в вашем методе множество условий, разбейте его на несколько. Это повысит читаемость, позволит легче поддерживать код и быстрее находить ошибки в нём. Вы полюбите улучшать код.
    Сохраняйте классы маленькими. Здесь применяется та же техника, что и с методами.
    Сначала придумайте решение задачи, потом напишите код. Никогда не поступайте иначе. Многие разработчики придумывают решение задачи во время написания кода, и в этом нет ничего плохого. Вы можете делать так и при этом придерживаться выше этого правила. Если вы можете в уме разбивать задачу на более мелкие части, когда вы пишете код, делайте это любыми способами. И не бойтесь переписывать код ещё, ещё и ещё… В счёт не идёт число строк, до тех пор пока вы считаете, что можно ещё меньше/ещё лучше.
    Не бойтесь избавляться от кода. Изменение старого кода и написание нового решения — два важных момента. Если вы столкнулись с новыми требованиями, или не были оповещены о них ранее, тогда порой лучше придумать новое, более изящное решение, решающее и старые, и новые задачи.

Статья о KISS (eng.): http://people.apache.org/~fhanik/kiss.html
Принцип YAGNI

Принцип YAGNI («You aren't gonna need it»; «Вам это не понадобится»): не пишите код, который, как вам кажется, может пригодиться в будущем, но сейчас в нём потребности нет. Вскоре он станет неактуальным или его придётся переписать под конкретную задачу.

Согласно сторонникам принципа YAGNI, желание писать код, который не нужен прямо сейчас, но может понадобиться в будущем, приводит к следующим нежелательным последствиям:

    Тратится время, которое было бы затрачено на добавление, тестирование и улучшение необходимой функциональности.
    Новые функции должны быть отлажены, документированы и сопровождаться.
    Новая функциональность ограничивает то, что может быть сделано в будущем, — ненужные новые функции могут впоследствии помешать добавить новые нужные.
    Пока новые функции действительно не нужны, трудно полностью предугадать, что они должны делать, и протестировать их. Если новые функции тщательно не протестированы, они могут неправильно работать, когда впоследствии понадобятся.
    Это приводит к тому, что программное обеспечение становится более сложным (подчас чрезмерно сложным).
    Если вся функциональность не документирована, она может так и остаться неизвестной пользователям, но может создать различные риски для безопасности пользовательской системы.
    Добавление новой функциональности может привести к желанию ещё более новой функциональности, приводя к эффекту «снежного кома».

YAGNI минимизирует объём ненужной работы и тесно связан с принципом KISS: избегать добавления функций и повышения сложности кода до тех пор, пока это действительно не понадобится.