Глава 2. Содержательные имена
2.1 Имена должны передавать намерения программиста
2.2 Избегайте дезинформации
2.3 Используйте осмысленные различия
2.4 Используйте удобопроизносимые имена
2.5 Выбирайте имена, удобные для поиска
2.6 Избегайте схем кодирования имен
2.7 Избегайте мысленных преобразований
2.8 Избегайте остроумия
2.9 Выберите одно слово для каждой концепции
2.10 Воздержитесь от каламбуров
2.11 Используйте имена из пространства решения
2.12 Используйте имена из пространства задачи
2.13 Добавьте содержательный(!) контекст
2.14 Не добавляйте избыточный контекст
Глава 3. Функции
3.1 Функции должны быть компактными. Желательно, длина функции не должна превышать 20 строк.
3.2 Функция должна выполнять только одну операцию. И только! Но выполнять очень хорошо.
3.3 Один уровень абстракции на функцию
3.4 Чтение кода сверху-вниз: Правило понижения. Код должен читаться как рассказ — сверху-вниз.
3.5 Используйте содержательные имена. Не стоит бояться использовать длинные имена! Длинное содержательное имя лучше короткого невразумительного.
3.6 Аргументы функций. Функции с 3 аргументами желательно избегать.
3.7 Избавьтесь от побочных эффектов. Функция не должна выполнять действия которые не указаны в ее имени.
3.8 Выходных аргументов следует избегать. Если функция должна изменять состояние какого-то объекта, то пусть изменяет объекта-владельца.
3.9 Разделять команды и запросы. Функция либо должна что-то делать, либо отвечать на какой-то запрос. Но не одновременно! Такие функции следует разделить.
3.10 Используйте исключения вместо возвращения кодов ошибок
3.11 Изолируйте блоки try/catch
4. Комментарии
4.1 Не комментируйте плохой код — перепишите его.
4.2 Хорошие комментарии
— Юридические комментарии
— Информативные комментарии
— Представление намерений
— Прояснение
— Предупреждение о последствиях
— Комментарии ToDo
— Усиление
— Комментарии JavaDoc в общедоступных API
4.3 Плохие комментарии
— Бормотание. Любой коммент смысл которого надо искать в других модулях, не несет никакого смысла.
— Избыточный коммент. Тот который загромождает, не проясняет, усложняет.
— Недостоверные комменты
— Обязательные комменты
— Журнальные комменты
— Шум
— Опасный шум
— Не использовать коммент там, где можно использовать функцию или переменную
— Закомментированный код. Удалять! Не оставлять!
5. Форматирование
— Газетный формат. Исходный код(класс) должен выглядеть как газетная статья. Имя файла должно быть простым но содержательным. Начальные блоки описывают высокоуровневые концепции и алгоритмы, а в самом конце собираются все функции и подробности низшего уровня.
6. Объекты и структуры данных
7. Обработка ошибок
8. Границы
Необходимо чтобы наш код знал о специфических подробностях реализации стороннего кода.