Как писать код для «будущего себя»

Перевод статьи «Writing code for your future self».

Со всеми нами такое случалось. Пишешь кусок кода, читаешь и думаешь, что он прекрасен. Ведь на момент написания все совершенно понятно. Возвращаешься к этому коду через год и оказывается, что там невозможно ничего разобрать.

Проблема в том, что вы пишете код для себя в настоящем. Вместо этого следует писать для себя в будущем. Обязательно задавайте себе вопрос: «Поймет ли «будущий я» предназначение этого блока кода?».

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

Не пытайтесь произвести на себя впечатление

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

Поэтому, если хотите сделать что-то действительно впечатляющее, напишите читабельный код.

Используйте осмысленные имена

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

«В ИНФОРМАТИКЕ ЕСТЬ ТОЛЬКО ДВЕ СЛОЖНЫЕ ВЕЩИ: АННУЛИРОВАНИЕ КЭША И ВЫБОР ИМЕН» © Фил Карлтон.

И хотя навык подбора имени можно развивать, я замечаю, что многие либо не уделяют этому достаточного внимания, либо имеют склонность перемудрить. Вот несколько правил, которые помогают мне в этом деле:

• Держаться подальше от слишком общих имен, таких как container или data.
• Использовать :

1. префиксы для булевых выражений (даже в типизированных языках), например, is или has.
2. такие префиксы как get или create для функций – чтобы указать на действие.
3. префиксы вроде min или total для лучшего описания чисел.
4. правильное множественное число при создании массивов, например, users.

• Избегать однобуквенных обозначений переменных, таких как «е». Вместо этого лучше использовать event или error.
• Не бояться длинных многословных имен вроде getTotalDaysSinceLastLogin.

И, самое главное, следует по возможности уменьшать потенциальную путаницу.

Разделяйте свои условия

Ядром многих приложений является логика, которая на самом деле просто сводится к if-предложениям. Условия при этом могут стать довольно сложными.

Сколько времени у вас уйдет, чтобы понять логику этого кода?

Время имеет большое значение. Безусловно, в конечном итоге я пойму смысл этого отрывка. Но если так будет написана вся кодовая база, то любой человек, который будет заниматься ее поддержкой (включая вас), вырвет себе все волосы, пытаясь ее понять.

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

А если добавилось еще одно условие? Создадим еще одну переменную.

Прочитав этот код в будущем, вы сразу поймете, что в нем происходит.

Создание функций с единственной ответственностью

Каюсь, я виновен в написании функций init() с сотнями строк кода, делающих множество вещей. Такие функции просто создавать, но, к сожалению, в будущем такой код будет совершенно не гибким.

Бороться с этим можно, следуя принципу единственной ответственности. Он заключается в том, что каждая отдельная функция должна отвечать лишь за маленький кусочек функционала.

Давайте рассмотрим пример проверки имени пользователя.

Здесь до определенной степени соблюдается принцип единственной ответственности, ведь единственное действие – проверка имени. Однако, мы здесь запускаем несколько разных проверок, плюс запрос к базе данных. Также у нас нет уверенности, что все это работает.

Мы можем разбить эту функцию на более мелкие.

Теперь эти функции легче менять, перемещать и тестировать.

Вы будете благодарны себе за все это

А также вам будет благодарен каждый, кому придется работать с написанным вами кодом.

Источник: techrocks.ru