Мелочи важны. Повышенное внимание к мелочам характерно для великих творцов. Стихотворение никогда не бывает законченным. Фальшивая монета всегда возвращается владельцу.

Качество возникает в результате миллиона проявлений небезразличия отношения к делу, а не от применения какого-то великого метода.

Функция должна выполнять только одну операцию, она должна выполнять ее хорошо и ничего другого делать не должна.

Один уровень абстракции на функцию

В идеальном случае количество аргументов функции равно 0. Аргументы-флаги уродливы Выходных аргументов следует избегать. Концепции, связанные друг с другом, должны находиться поблизости друг от друга по вертикали в коде.

Объекты предоставляют поведение и скрывают данные Не возвращайте null

Принцип единой ответственности - класс или модуль должен иметь одну причину для изменения.

Используйте самое простое решение из всех возможных.

Чтобы написать чистый код, мы сначала пишем грязный код, а затем очищаем его.

Комментарии должны говорить то, что не скажет сам код.

Лучше иметь несколько функций, чем передавать функции признак для выбора поведения.

Длина имени должна соответствовать его области видимости.

Не используйте имена, передающие информацию о реализации. Имена должны отражать уровень абстракции, на котором работает класс или функция.

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

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

Все операторы в функции должны находиться на одном уровне абстракции, который должен быть на один уровень ниже операции, описываемой именем функции.

Изучение чужого кода – непростая задача. Интеграция чужого кода тоже сложна. Одновременное решение обоих задач создает двойственные сложности. А что, если пойти по другому пути? Вместо того, чтобы экспериментировать и опробовать новую библиотеку в коде продукта, можно написать тесты. Проверяющие наше понимание стороннего кода. Джим Ньюкирк (JimNewkirk) называет такие тесты «учебными тестами».