ПЕРЕДМОВА
ВСТУП
ПОДЯКИ
РОЗДІЛ 1. ЧИСТИЙ КОД
Хай живе код
Поганий код
Розплата за хаос
Грандіозне перероблення
Відносини
Головний парадокс
Мистецтво чистого коду?
Що таке «чистий код»?
Школи думки
Ми — автори
Правило бойскаута
Передісторія й принципи
Висновки
Література
РОЗДІЛ 2. ЗМІСТОВНІ ІМЕНА
Імена мають передавати наміри програміста
Уникайте дезінформації
Використовуйте осмислені відмінності
Використовуйте імена, що зручно вимовляти
Вибирайте імена, зручні для пошуку
Уникайте схем кодування імен
Угорський запис
Префікси членів класів
Інтерфейси та реалізації
Уникайте ментальних перетворень
Імена класів
Авторизований переклад з англомовного видання під назвою
CLEAN CODE: A HANDBOOK OF AGILE SOFTWARE CRAFTSMANSHIP, 1-ше видання, автора Роберта Мартіна, опублікованого Pearson Education, Inc, що виступає як Prentice Hall4
Імена методів
Уникайте дотепів
Виберіть одне слово для кожної концепції
Утримуйтеся від каламбурів
Надавайте імена в термінах рішення
Надавайте імена в термінах задачі
Додайте змістовний контекст
Не додавайте надлишкового контексту
Кілька слів наостанок
РОЗДІЛ 3. ФУНКЦІЇ
Компактність!
Блоки й відступи
Правило однієї операції
Секції у функціях
Один рівень абстракції на функцію
Читання коду згори вниз: правило зниження
Команди switch
Використовуйте змістовні імена
Аргументи функцій
Стандартні унарні форми
Аргументи-прапори
Бінарні функції
Тернарні функції
Об’єкти як аргументи
Списки аргументів
Дієслова й ключові слова
Позбавтеся побічних ефектів
Вихідні аргументи
Поділ команд і запитів
Використовуйте винятки замість повернення кодів помилок
Виділіть блоки try / catch
Оброблення помилок як одна операція
Магніт залежностей error.java
Не повторюйтеся
Структурне програмування
Як навчитися писати такі функції?
Висновок
Література
РОЗДІЛ 4. КОМЕНТАРІ
Коментарі не компенсують поганого коду
Поясніть свої наміри в коді
Гарні коментарі
Юридичні коментарі
Інформативні коментарі
Презентування намірів
Прояснення
Попередження про наслідки
Коментарі TОDО
Посилення
Коментарі javadoc у загальнодоступних API
Погані коментарі
Бурмотіння
Надлишкові коментарі
Недостовірні коментарі
Обов’язкові коментарі
Журнальні коментарі
Шум
Небезпечний шум
Не використовуйте коментарі там, де можна використати функцію або змінну
Позиційні маркери
Коментарі за закритою фігурною дужкою
Посилання на авторів
Закоментований код
HTML коментарі
Нелокальна інформація
Занадто багато інформації
Неочевидні коментарі
Заголовки функцій
Заголовки javadoc у внутрішньому коді
Приклад
Література
РОзДіл 5. ФОРМАТУВАння
Мета форматування
Вертикальне форматування
Газетна метафора
Вертикальний розподіл концепцій
Вертикальне стиснення
Вертикальні відстані
Вертикальне впорядкування
Горизонтальне форматування
Горизонтальний розподіл і стиснення
Горизонтальне вирівнювання
Відступи
Вироджені ділянки видимості
Правила форматування в командах
Правила форматування від дядечка Боба
РОЗДІЛ 6. ОБ’ЄКТИ й СТРУКТУРИ ДАНИХ
Абстракція даних
Антисиметрія даних/об’єктів
Закон Деметри
«Аварія потяга»
Гібриди
Приховування структури
Об’єкти передання даних
Активні записи
Висновки
Література
РОЗДІЛ 7. ОБРОБЛЕННЯ ПОМИЛОК (Майкл Фізерс)
Використовуйте винятки замість кодів помилок
Почніть із написання команди try-catch-fnally
Використовуйте неперевірні винятки
Передавайте контекст із винятками
Визначайте класи винятків у контексті потреб викличної сторони
Визначте нормальний шлях виконання
Не повертайте null
Не передавайте null
Висновки
Література
РОЗДІЛ 8. МЕЖІ
Використання стороннього коду
Дослідження та аналіз меж
Вивчення log4j
Навчальні тести: вигідніше, ніж безкоштовно
Використання неіснуючого коду
Чисті межі
Література
РОЗДІЛ 9. МОДУЛЬНІ ТЕСТИ
Три закони TDD
Про чистоту тестів
Тести як засіб забезпечення змін
Чисті тести
Предметно-орієнтована мова тестування
Подвійний стандарт
Одна перевірка на тест
Одна концепція на тест
FIRST
Висновки
Література
РОЗДІЛ 10. КЛАСИ (спільно з Джеффрі ланґром)
Будова класу
Інкапсуляція
Класи мають бути компактними!
Принцип єдиної відповідальності (SRP)
Зв’язність
Підтримання зв’язності призводить до зменшення класів
Структурування з урахуванням змін
Ізоляція змін
Література
РОЗДІЛ 11. СИСТЕМИ (Кевін Дін Вомплер)
Як би ви будували місто?
Відокремлення конструювання системи від її використання
Відокремлення main
Фабрики
Впровадження залежностей
Масштабування
Перехресні ділянки відповідальності
Посередники
АОП-інфраструктури «чистою» java
Аспекти Aspectj
Випробування системної архітектури
Оптимізація прийняття рішень
Застосовуйте стандарти розумно, коли вони приносять очевидну користь
Системам необхідні предметно-орієнтовані мови
Висновки
Література
РОЗДІЛ 12. ФОРМУВАННЯ АРХІТЕКТУРИ (Джефф Ланґр)
Чотири правила
Правило № 1: виконання всіх тестів
Правила № 2–4: перероблення коду
Відсутність дублювання
Виразність
Мінімум класів і методів
Висновки
Література
РОЗДІЛ 13. БАГАТОПОТОКОВІСТЬ (Бретт Л. Шухерт)
Навіщо потрібна багатопотоковість?
Міфи й неправильні уявлення
Труднощі
Захист від помилок багатопотоковості
Принцип єдиної відповідальності
Наслідки: обмежуйте ділянку видимості даних
Наслідки: використовуйте копії даних
Наслідки: потоки мають бути якомога більш незалежними
Знайте свою бібліотеку
Потоково-безпечні колекції
Знайте моделі виконання
Модель «виробник / споживач»
Модель «читач / письменник»
Модель «філософи за обідом»
Остерігайтеся залежностей між синхронізованими методами
Синхронізовані секції повинні мати мінімальний розмір
Про труднощі коректного завершення
Тестування багатопотокового коду
Розглядайте неперіодичні збої як ознаки можливих проблем багатопотоковості
Почніть із налагодження основного коду, не пов’язаного з багатопотоковістю
Реалізуйте перемикання конфігурацій багатопотокового коду
Забезпечте логічну ізоляцію конфігурацій багатопотокового коду
Протестуйте програму з кількістю потоків, що перевищує кількість процесорів
Протестуйте програму на різних платформах
Застосовуйте інструментування коду для підвищення ймовірності виявлення збоїв
Ручне інструментування
Автоматизоване інструментування
Висновки
Література
РОЗДІЛ 14. ПОСЛІДОВНЕ ОЧИЩЕННЯ (Справа про розбирання аргументів командного рядка)
Реалізація Args
Як я це зробив?
Args: чернетка
На цьому я зупинився
Про поступове вдосконалення
Аргументи String
Висновки
РОзДіл 15. ВнУТРішня бУДОВА junit
Фреймворк JUnit
Висновки
РОзДіл 16. ПЕРЕРОблЕння SERiALDAtE
Перш за все — змусити працювати...Потім очистити код
Висновки
Література
РОЗДІЛ 17. «ЗАПАХИ» ТА ЕВРИСТИЧНІ ПРАВИЛА
Коментарі
C1: Недоречна інформація
C2: Застарілий коментар
C3: Надмірний коментар
C4: Погано написаний коментар
C5: Закоментований код
Робоче середовище
e1: Збирання складається з декількох етапів
e2: Тестування складається з декількох етапів
Функції
F1: Забагато аргументів
F2: Вихідні аргументи
F3: Прапори в аргументах
F4: Мертві функції
Різне
G1: Кілька мов в одному вихідному файлі
G2: Очевидна поведінка не реалізован
G3: Некоректна межова поведінка
G4: Відімкнені засоби безпеки
G5: Дублювання
G6: Код на неправильному рівні абстракції
G7: Базові класи, залежні від похідних
G8: Забагато інформації
G9: Мертвий код
G10: Вертикальний розподіл
G11: Непослідовність
G12: Баласт
G13: Штучні прив’язки
G14: Функціональна заздрість
G15: Аргументи-селектори
G16: Незрозумілі наміри
G17: Неправильне розміщення
G18: Недоречні статичні методи
G19: Використовуйте пояснювальні змінні
G20: Імена функцій повинні описувати виконувану операцію
G21: Розуміння алгоритму
G22: Перетворення логічних залежностей на фізичні
G23: Використовуйте поліморфізм замість if/else або switch/сase
G24: Дотримуйте стандартних конвенцій
G25: Заміняйте «чарівні числа» іменованими константами
G26: Будьте точні
G27: Структура важливіша за конвенції
G28: Інкапсулюйте умовні конструкції
G29: Уникайте негативних умов
G30: Функції мусять виконувати одну операцію
G31: Приховані темпоральні прив’язки
G32: Структура коду має бути обґрунтована
G33: Інкапсулюйте межові умови
G34: Функції мають бути написані на одному рівні абстракції
G35: Зберігайте конфігураційні дані на високих рівнях
G36: Уникайте транзитивних звернень
java
j1: Використовуйте узагальнені директиви імпорту
j2: Не успадковуйте від констант
j3: Константи проти перерахувань
Імена
N1: Використовуйте змістовні імена
N2: Вибирайте імена на відповідному рівні абстракції
N3: За можливості використовуйте стандартну номенклатуру
N4: Недвозначні імена
N5: Користуйтесь довгими іменами для довгих зон видимості
N6: Уникайте кодування
N7: Імена повинні описувати побічні ефекти
Тести
T1: Брак тестів
T2: Використовуйте засоби аналізу покриття коду
T3: Не пропускайте тривіальні тести
T4: Відімкнений тест як питання
T5: Тестуйте межові умови
T6: Ретельно тестуйте код поруч із помилками
T7: Закономірності збоїв часто несуть корисну інформацію
T8: Закономірності покриття коду часто несуть корисну інформацію
T9: Тести повинні працювати швидко
Висновки
Література
ДОДАТОК А. бАгАТОПОТОКОВіСТь ii (бретт л. шухерт)
Приклад застосунку «клієнт/сервер»
Сервер
Реалізація багатопотоковості
Аналіз серверного коду
Висновки
Можливі шляхи виконання
Кількість шляхів
Обчислення можливих варіантів упорядкування
Копаємо глибше
Висновки
Знайте свої бібліотеки
executor Framework
Неблоковні рішення
Потоково-небезпечні класи
Залежності між методами можуть порушити роботу багатопотокового коду
Перенесення збоїв
Клієнтське блокування
Серверне блокування
Підвищення продуктивності
Обчислення продуктивності в однопотоковій моделі
Обчислення продуктивності в багатопотоковій моделі
Взаємне блокування
Взаємне виключення
Блокування з очікуванням
Відсутність витіснення
Циклічне очікування
Порушення взаємного виключення
Порушення блокування з очікуванням
Порушення відсутності витіснення
Порушення циклічного очікування
Тестування багатопотокового коду
Засоби тестування багатопотокового коду
Висновки
Повні приклади коду
Однопотокова реалізація архітектури «клієнт/сервер»
Архітектура «клієнт/сервер» з використанням потоків
ДОДАТОК В. ОRG.JFREE.DATE.SERIALDATE
ДОДАТОК С. ПЕРЕХРЕСНІ ПОСИЛАННЯ
ЕПІЛОГ
ПОКАЖЧИК