Чистый код. Создание, анализ и рефакторинг

Ничто так не раздражает, как висящий в конце вызова функции аргумент false. Зачем он здесь? Что изменится, если этот аргумент будет равен true? Смысл селектора трудно запомнить, но дело не только в этом — селектор указывает на объединение нескольких функций в одну. Аргументы-селекторы помогают ленивому программисту избежать разбиения большой функции на несколько меньших. Пример:

public int calculateWeeklyPay(boolean overtime) {

  int tenthRate = getTenthRate();

  int tenthsWorked = getTenthsWorked();

  int straightTime = Math.min(400, tenthsWorked);

  int overTime = Math.max(0, tenthsWorked - straightTime);

  int straightPay = straightTime * tenthRate;

  double overtimeRate = overtime ? 1.5 : 1.0 * tenthRate;

  int overtimePay = (int)Math.round(overTime*overtimeRate);

  return straightPay + overtimePay;

}

Функция вызывается с аргументом true при оплате сверхурочной работы по полуторному тарифу или с аргументом false при оплате по стандартному тарифу. Каждый раз, когда вы встречаете вызов calculateWeeklyPay(false), вам приходится вспоминать, что он означает, и это само по себе неприятно. Но по-настоящему плохо то, что автор поленился использовать решение следующего вида:

public int straightPay() {

  return getTenthsWorked() * getTenthRate();

}

public int overTimePay() {

  int overTimeTenths = Math.max(0, getTenthsWorked() - 400);

  int overTimePay = overTimeBonus(overTimeTenths);

  return straightPay() + overTimePay;

}

private int overTimeBonus(int overTimeTenths) {

  double bonus = 0.5 * getTenthRate() * overTimeTenths;

  return (int) Math.round(bonus);

}

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

G16: Непонятные намерения

Код должен быть как можно более выразительным. Слишком длинные выражения, венгерская запись, «волшебные числа» — все это скрывает намерения автора. Например, приводившаяся ранее функция overTimePay могла бы выглядеть и так:

public int m_otCalc() {

  return iThsWkd * iThsRte +

    (int) Math.round(0.5 * iThsRte *

      Math.max(0, iThsWkd - 400)

    );

}

Такая запись выглядит компактной и плотной, но разбираться в ней — сущее мучение. Не жалейте времени на то, чтобы сделать намерения своего кода максимально прозрачными для читателей.

G17: Неверное размещение

Одно из самых важных решений, принимаемых разработчиком, — выбор места для размещения кода. Например, где следует объявить константу PI? В классе Math? А может, ей место в классе Trigonometry? Или в классе Circle?

В игру вступает принцип наименьшего удивления. Код следует размещать там, где читатель ожидает его увидеть. Константа PI должна находиться там, где объявляются тригонометрические функции. Константа OVERTIME_RATE объявляется в классе HourlyPayCalculator.

Иногда мы пытаемся «творчески» подойти к размещению функциональности. Мы размещаем ее в месте, удобном для нас, но это не всегда выглядит естественно для читателя кода. Предположим, потребовалось напечатать отчет с общим количеством отработанных часов. Мы можем просуммировать часы в коде, печатающем отчет, или же накапливать сумму в коде обработки учетных карточек рабочего времени.

Чтобы принять решение, можно посмотреть на имена функций. Допустим, в модуле отчетов присутствует функция с именем getTotalHours, а в модуле обработки учетных карточек присутствует функция saveTimeCard. Какая из этих двух функций, если судить по имени, наводит на мысль о вычислении суммы? Ответ очевиден.

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

G18: Неуместные статические методы