Не дублировать код

Не дублировать код
Размещать как можно больше кода в Core, размещать в Core любой код,
который может быть использован в другом проекте; Использовать иерархии
наследования, включаемые компоненты, расширяющие методы
Не дублировать семантику
Для решения одной задачи использовать только один механизм (класс, метод,
атрибут). Допускается создание перегруженных методов со значениями по
умолчанию
Не делать переменную
семантику
Семантика (назначение) метода, класса или переменной быть всегда
одинаковой при любых условиях и должна точно отражаться его названием.
См. SRP
Не делать длинных методов
Разбивать логику на классы и методы
Минимально использовать
числовые и строковые
константы, коды возврата и т.
д.
Использовать типизацию: перечисления, структуры, классы, исключения
Не выставлять наружу лишние
члены класса
У класса должно быть минимальное количество публичных членов. Принцип
инкапсуляции не должен нарушаться. У пользователя класса должно быть
минимум возможностей сломать экземпляр класса. Если это всё-таки
происходит должно выбрасываться исключение. При использовании класса
минимально использовать знания о его реализации, так как она может
измениться и код, использующий эти знания перестанет работать.
Независимость реализаций
Реализация одного класса не должна зависеть от реализации другого класса. То
есть при условии неизменности публичного интерфейса, изменение в
реализации одного класса не должно требовать изменения реализации другого
класса для сохранения прежней функциональности приложения с точки зрения
пользователя
Публичный интерфейс должен быть минимальным
Область видимость должна быть минимальной (не делать глобальных
переменных)
Избегать перекрёстных ссылок между классами
Параметрами конструктора класса могут быть только переменные для
инициализации private или public readonly полей, то есть те поля, которые
нельзя модифицировать после инстанцирования (вызова конструктора). Для
повышения гибкости и для уменьшения числа необходимых классов,
желательно минимизировать количество полей, которые нельзя
модифицировать после инстанцирования
Условия в if, которые всегда возвращают одно значение (true или false),
должны отсутствовать.
При объявлении переменных или параметров методов использовать наиболее
базовые классы (для увеличения повторной используемости)
Принцип подстановки Лисков
(честный полиморфизм)
Относится к построению иерархий наследования. Предположим, есть класс A, у
него наследник B. Есть код, в котором объявлена переменная V(параметр
метода, поле класса) класса A. В эту переменную записывается объект класса B.
Далее создается еще один наследник класса A: C. В переменную V теперь
может записывать как объект класса B, так и объект класса С. В этом случае
вышеупомянутый код не должен требовать модификации. См.
http://blog.byndyu.ru/2009/10/blog-post_29.html
При объявлении типов возвращаемых из методов использовать наиболее
конкретный тип, за исключением ситуаций, когда в последствии планируется
изменить реализацию метода на реализацию, при которой возвращается
другой тип, не являющийся наследником по отношению к исходному типу.
Не размещать в базовых
классах методы, которые
нужны не всем классам
наследникам
Не делать заплатки (особенно
в Core), ограничивающие
область применения
В базовых классах должна размещаться логика нужная всем классам
наследникам

Искать причину корневую ошибки, устранять причину ошибки, а не
следствие.

Заплатки допустимы при аварийном (срочном) исправлении проблемы.

Код заплатки должен быть помечен комментарием.
Не глотать исключения
Если в программе возможна ситуация, при которой она будет работать
неправильно, то, должно выбрасываться исключение с подробным
объяснением на самых ранних этапах развития ситуации
Соблюдать систему
именования

Одни и те же вещи называть одинаково (желательно и в БД). Это нужно,
чтобы при поиске по термину X, увидеть весь код, относящийся к X, не
меньше.

Не назвать разные вещи одинаково (желательно и в БД). Это нужно,
чтобы при поиске по термину X, не смотреть код не относящийся к X.

При алфавитной сортировке методы, классы одной смысловой группы
должны оказаться рядом.

Код должен быть максимально самодокументированным, смысл
названия переменных, классов должен быть понятен без комментариев
или с минимальных их количеством.

Название метода или класса должно точно отражать то, что он делает.
Если получается что метод делает больше, чем то, что написано в его
названии, это сигнал к тому, чтобы разбить логику на насколько классов
или методов

В названиях не использовать не общепринятых сокращений

Лучше понятное, но длинное название, чем непонятное, но короткое.
“Понятное” в данном случае означает, удовлетворяющие правилам
приведённым выше.

Название метода должно быть глаголом, за исключением свойств и
методов обработчиков событий (XHandler, OnX)

Название класса должно быть существительным

В большинстве случаев название интерфейса должно быть наречием (able) или существительным, заканчивающимся на -er

Название переменной не должно быть глаголом

Название события должно быть Xing или BeforX, если событие
происходит до X, или Xed или AfterX, если событие происходит после X.
Использовать XML комментарии