Вот мои конспекты из онлайн-курса LinkedIn Clean Code.

Что такое чистый код

  • Написано с мыслью о людях— люди как основная аудитория
  • Имена легко понять
  • Отформатировано последовательно — форматирование влияет на читабельность
  • Четко сообщает о намерениях

Итак, код:

  • Легко читать
  • Легко улучшить
  • Легко исправить

Чистые имена

Первое правило: избегайте однобуквенных имен!

  • Предпочитайте ясность краткости
    —    Распространенные ошибки: слишком короткие имена переменных для циклов и массивов.
  • Акронимы и аббревиатуры
    — HTTPAPIClient и HttpApiClient: небольшое изменение поможет избежать путаницы
    — Избегайте аббревиатур, если они не очень распространены.

Имена классов и типов

  • Предпочитайте существительные для имен классов (например, Performer лучше, чем Performance)
  • Используйте префиксы прилагательных для обозначения времени (например, PastPerformer)
  • Избегайте нечетких префиксов и однобуквенных префиксов (исключение: языки с шаблонами).
  • Избегайте всех аббревиатур с заглавными буквами — легче увидеть границу между аббревиатурами.
  • Избегайте множественного числа в обычном классе, за исключением классов коллекций.

Имена методов и функций

  • Используйте настоящее время
  • Избегайте герундия (например, performing, validating), используйте is_performing, is_validating и т. д.
  • Избегайте прошедшего времени: используйте настоящее совершенное has_performed, has_validated и т. д.
  • Методы доступа начинаются с get

Имена переменных

  • Существительные в единственном числе: для примитивных типов и ссылок на объекты.
  • Существительные во множественном числе: для массивов и других коллекций.
  • Избегайте глаголов для переменных примитивного типа:преобразуйте их в форму существительного/глагола прошедшего времени. (например, retry -> retryEnabled )
  • Переменные Lambda: следуйте именам методов и функций
  • Разделяйте акронимы и расшифровывайте аббревиатуры. Не путайте акронимы и аббревиатуры.
  • Избегайте использования имени типа в качестве суффикса (например, lastNameString).

Имена параметров

  • Аналогично именам переменных

Постоянные имена

  • Правила для существительных в единственном числе и во множественном числе такие же, как и для переменных.
  • ENUM имена должны быть в единственном числе
  • Точные правила форматирования соответствуют конкретному используемому языку. Что-то, что работает для C++, может не подойти для Kotlin.

Чистое форматирование

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

Если возможно, установите глобальный стиль кода и примените автоматическое форматирование кода, чтобы сделать код согласованным в рамках проекта. Это особенно важно, когда мы работаем в команде.

Отступ и размещение скобок

  • Выберите табуляцию или пробелы, но не то и другое одновременно
  • Последовательность является ключевым

Перенос строки

  • Чрезвычайно длинные строки могут быть трудночитаемыми

пробел

  • Добавьте пустую строку перед оператором return
  • Добавляйте пустую строку перед любым кодом, что делает логический фрагмент похожим на абзац.
  • И пустая строка перед каждым куском кода с комментарием

Комментарии

  • Лучшие комментарии отвечают на вопросы «почему».
  • Худшие комментарии отвечают на вопросы «что». Мы должны применять методы рефакторинга, если код сложен для понимания.
// This comment is redundant.
// Assigning phone number as the contact id
val contactId: String = phoneNumber

Чистая логика

  • Магические числа и константы: храните значения как константы с описательным именем.

Списки параметров

  • Чем меньше параметров принимает метод, тем легче определить, для чего используется каждый параметр при вызове метода. (Kotlin: используйте именованные аргументы)
  • Соберите аргументы, используя объекты, если это необходимо. (Kotlin: класс данных может быть полезен)

Предикативные методы

  • Сложная логическая логика: оборачивает или инкапсулирует логическую логику в метод-предикат с понятным и описательным именем того, что проверяется.

Правильное использование петель

  • Третье правило: не повторяйтесь более одного раза. «Три или больше? Используйте для!»

Чистые модульные тесты

Тесты по-прежнему являются кодом, поэтому мы по-прежнему должны следовать правилам чистого кода.

Держите тесты быстро

  • Иначе люди не захотят их запускать!

Одно утверждение на тест

  • Модульные тесты — это документация — создавайте их с учетом этого!
  • Модульные тесты сфокусированы. У каждого модульного теста есть только одна причина неудачи, потому что он проверяет только одну конкретную деталь за раз.
  • Когда отдельный тест содержит несколько утверждений, каждое из них является отдельной причиной, по которой тест может провалиться.
  • Это экономит нам время, когда нам нужно обнаружить, где существует ошибка.

Держите тесты изолированными

  • Каждый тест можно запускать независимо и в любом порядке

СУХИЕ и ВЛАЖНЫЕ тесты

  • Чистые модульные тесты поддерживают баланс между понятностью и ясностью, не полагаясь на дублирование и скопированные фрагменты кода.
  • Используйте общую инициализацию, например @BeforeEach
  • Если у нас есть длинный список модульных тестов, выполняющих одно и то же, но с разными значениями, попробуйте @ParameterizedTest с MethodSource.

Рекомендации