Это Пятнадцатый Шаг к прохождению серии Программирование Просветление». Если вы не выучили Четырнадцатый шаг, прочтите его.
«Плохие программисты беспокоятся о коде.
Хорошие программисты беспокоятся о структурах данных и их взаимосвязях», — Линус Торвальдс.
Рассуждайте себя или подвергайте сомнению свои действия, это то, что должен делать каждый, будь то в жизни или на работе. Это в равной степени относится и к кодированию. Нам постоянно приходится внедрять функции в производство по мере необходимости. Когда это бизнес-решение входит в кодирование, оно может быть реализовано или не полностью реализовано в продукте. Именно здесь вступают в действие рассуждения или сомнения в реализации.
Как обосновать свой код?
Будь то уже реализованная функция или разработка новой, мы должны начать с наименьшего фрагмента, над которым мы можем работать в данный момент времени. Это может быть один оператор для блока, который находится внутри вызова метода. Нам нужно обосновать существование каждого утверждения, играющего роль адвоката дьявола с самим собой или со сверстником.
«(Нет) такого понятия, как глупый вопрос». ~ Карл Саган.
Зачем обосновывать свой код?
Размышление над вашим кодом приводит к тому, что мы носим другую шляпу и видим с другой точки зрения. Много раз, просто говоря о проблеме с вашим сверстником, вы можете испытать некоторый момент озарения, и решение просто есть. Кроме того, мы можем попытаться взять на себя ответственность QA и оценить свойства конечной точки с предусловием и постусловием.
Это поможет нам превратить код в отдельные независимые разделы, где ошибки можно будет легко отследить или сделать без ошибок.
Советы по обоснованию кода?
Неудивительно, что большинство упомянутых советов можно проверить с помощью статических анализаторов кода.
- Избегайте использования операторов goto, так как они делают удаленные разделы очень взаимозависимыми.
- Избегайте использования изменяемых глобальных переменных, поскольку они делают зависимыми все разделы, в которых они используются.
- Каждая переменная должна иметь наименьшую возможную область действия. Например, локальный объект может быть объявлен непосредственно перед его первым использованием.
- Делайте объекты неизменяемыми, когда это уместно.
- Сделайте код читабельным, используя интервалы как по горизонтали, так и по вертикали. Например, выравнивание связанных структур и использование пустой строки для разделения двух разделов.
- Сделайте самодокументирующийся код, выбрав описательные (но относительно короткие) имена для объектов, типов, функций и т. д.
- Избегайте вложенного раздела вложенного раздела, если он вам нужен, сделайте его функцией.
- Сделайте свои функции краткими и сосредоточьтесь на одной задаче. Старое ограничение в 24 строки остается в силе. Хотя размер экрана и разрешение изменились, с 1960-х годов ничего не изменилось в человеческом познании.
- Функции должны иметь несколько параметров (четыре — хорошая верхняя граница). Это не ограничивает данные, передаваемые функциям: группировка связанных параметров в один объект выигрывает от инвариантов объекта и экономит рассуждения, такие как их согласованность и согласованность.
- В более общем смысле каждая единица кода, от блока до библиотеки, должна иметь узкий интерфейс. Меньше общения уменьшает требуемое рассуждение. Это означает, что геттеры, возвращающие внутреннее состояние, являются помехой — не запрашивайте у объекта информацию для работы. Вместо этого попросите объект выполнить работу с уже имеющейся у него информацией. Другими словами, инкапсуляция касается только узких интерфейсов.
- Чтобы сохранить инварианты класса, использование сеттеров должно быть не рекомендуется, так как сеттеры склонны позволять нарушать инварианты, управляющие состоянием объекта.
TL;DR Какое-то время вы можете показаться глупым, но обоснование ваших предположений всегда поможет улучшить наш код и нашу интуицию.
Перейдите к Шестнадцатый шаг.
Перейти к следующему пути (скоро).
Ссылки:
- 97 вещей, которые должен знать каждый программист ~ Git Book
- 97 вещей, которые должен знать каждый программист ~ Мягкая обложка
- Почему ограничение в 24 строки? ~ Обмен стеками
- Список инструментов статического анализа кода ~ Wiki
- Советы по улучшению кода-ревью ~ блог Github