Это Пятнадцатый Шаг к прохождению серии Программирование Просветление». Если вы не выучили Четырнадцатый шаг, прочтите его.

«Плохие программисты беспокоятся о коде.

Хорошие программисты беспокоятся о структурах данных и их взаимосвязях», — Линус Торвальдс.

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

Как обосновать свой код?

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

«(Нет) такого понятия, как глупый вопрос». ~ Карл Саган.

Зачем обосновывать свой код?

Размышление над вашим кодом приводит к тому, что мы носим другую шляпу и видим с другой точки зрения. Много раз, просто говоря о проблеме с вашим сверстником, вы можете испытать некоторый момент озарения, и решение просто есть. Кроме того, мы можем попытаться взять на себя ответственность QA и оценить свойства конечной точки с предусловием и постусловием.

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

Советы по обоснованию кода?

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

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

TL;DR Какое-то время вы можете показаться глупым, но обоснование ваших предположений всегда поможет улучшить наш код и нашу интуицию.

Перейти к сериалу.

Перейдите к Шестнадцатый шаг.

Перейти к следующему пути (скоро).

Ссылки: