15/97: Программируйте обоснованно

Это перевод Coding with Reason. Автор: Yechiel Kimchi.

Из "97-ми вещей, которые должен знать каждый программист".

Попытка рассуждать о правильности программного обеспечения вручную приводит к формальному доказательству, которое больше самого кода и, скорее всего, оно содержит ошибки вместо кода. Автоматические утилиты более предпочтительны, но их применение не всегда возможно. Ниже описан компромисс: полу-формальные рассуждения о правильности кода.

Смысл подхода кратко: вы делите весь код на короткие блоки — от одной строки, такой как вызов функции, до блоков менее 10 строк - и рассуждаете об их корректности. Ваши аргументы должны быть достаточно сильны, чтобы убедить вашего коллегу, играющего роль "адвоката дьявола".

Секция кода должна выбираться так, чтобы на каждой её границе состояние программы (а именно: текущая инструкция и значения всех "живых" объектов) удовлетворяли легко описываемому свойству, а функциональность этого блока кода (state transformation) легко бы описывалось одной простой задачей — эти условия позволят вам сделать ваши рассуждения проще. Такие свойства границ блока обобщают концепции типа пре- и пост-условий, инвариантов циклов и классов (по отношению к их экземплярам). Старайтесь, чтобы секции кода были как можно более независимыми друг от друга - это упрощает рассуждения и является необходимым, если эти секции будут изменяться.

Многие из хорошо известных практик кодирования (хотя, возможно, следуют им менее охотно) - это "хорошо" и они делают рассуждения проще. Значит, достаточно просто намерения рассуждать о своём коде, как вы уже начинаете думать в сторону лучшего стиля и структуры. Неудивительно, что большинство из этих методов может быть проверено статическими анализаторами кода:

1. Избегайте использования операторов goto, поскольку они делают удаленные друг от друга секции сильно связанными.
2. Избегайте использования изменяемых глобальных переменных, поскольку они делают секции, их использующие, зависимыми.
3. Каждая переменная должна иметь минимально возможную область видимости.
4. Делайте объекты неизменяемыми там, где только это возможно.
5. Делайте код легко читаемым, используя отступы как по горизонтали, так и по вертикали. К примеру, выделения связанных вещей в один блок и вставкой пустой строки между ними.
6. Делайте код само-документирующимся, выбирая описательные (но не чрезмерно длинные) имена объектов, типов, функций и т.п.
7. Если вам нужна вложенная секция кода - сделайте её функцией.
8. Делайте ваши функции короткими и сфокусированными на одной задаче. Хорошей прикидкой будет старое ограничение в 24 строки. Хотя изменились размеры мониторов, но в возможностях человеческого восприятия ничего не изменилось с 1960-тых.
9. Функции должны иметь небольшое количество параметров (4 - хорошая верхняя граница). Заметьте, что это не ограничивает набор данных для общения с функцией: вы можете группировать связанные параметры в один (объект или запись) - заодно обеспечив согласованность этих данных.
10. Говоря более общими словами, каждый модуль в коде (от блока кода до библиотеки) должен иметь минимально возможный интерфейс. Уменьшение области взаимодействия упрощает проверку корректности. Это означает, что get-методы, которые возвращают внутренние состояния, являются ответственностью - не спрашивайте у объекта информации для работы с ним. Вместо этого, попросите объект выполнить работу с информацией, как он сам умеет. Другими словами, инкапсуляция - это и есть минимальный интерфейс.
11. Чтобы сохранять инвариантность в классах, ограничьте использование set-методов, поскольку они могут нарушать инвариантность.

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