Иногда больше, больше.

Взгляните на этот (намеренно неаккуратный) пример кода JavaScript и подумайте, что такое условие if. Постарайтесь и помните, как вы это решаете.

Готов поспорить, хорошо, что вы начали читать внутреннюю часть блока if. Первые две или три строки ничего вам не говорят, но по мере того, как вы работали с этим утверждением, вы поняли, что это отправляемая форма, а через мгновение стало известно, что значения name и telephone в условии являются обязательными полями для формы. . Если вы похожи на меня, вы также должны прочитать до конца функции, чтобы убедиться, что это альтернативное условие подтвердило ваши подозрения.

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

Но что, если бы мы могли пойти еще лучше. Что, если бы само выражение if могло сказать вам, что оно делает, без необходимости сначала анализировать оба результата?

Теперь вы можете пропускать строки 5–7, если вас интересует только счастливый путь. В примере вверху вы можете пропустить строки 3–15. Одна строка ясно дает понять, что делает этот оператор if. В некоторых случаях это позволяет пропустить весь блок.

Если мы воспроизведем описанный выше подход к сканированию, мы получим следующее:

Почему это важно?

Во-первых, это объявление переменной несет важную информацию.

В первом примере вы можете увидеть одно: что написал разработчик.

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

Если вы знаете, что на самом деле email также является обязательным полем, вы можете увидеть, что разработчик допустил ошибку и пропустил ее. Они пытались проверить наличие обязательных полей, но забыли одно.

Возвращаясь к первому примеру вверху, пытался ли первоначальный разработчик проверить наличие обязательных полей? Они сделали ошибку? А может, они не проверяли обязательные поля? Есть ли какое-то отдельное поведение, если отсутствуют только name и telephone? Вы не знаете, что они пытались сделать, поэтому вам нужно прочитать все, чтобы убедиться, что это действительно все обязательные поля, которые они хотели проверить.

Во-вторых, это снимает некоторую нагрузку с вашей умственной рабочей памяти. Для меня самый быстрый способ запутать себя - это попытаться манипулировать множеством вещей в моей рабочей памяти.

Если вы не пишете const requiredFields = name && telephone; в своем коде, вы должны держать const requiredFields = name && telephone; в своей рабочей памяти в голове.

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

Аргументы

Вот наиболее частые аргументы, которые я слышал против этого подхода:

  1. Вы отправляете дополнительный код в браузер / дополнительный код для запуска. Угадайте, что? Я пропустил его через минификатор, и он минимизирует объявление этой переменной. Оба примера сводятся к одному и тому же!
  2. Есть еще код, который нужно прочитать: кода больше, но вы читаете меньше. Вам не нужно читать объявление переменной, если вас не интересует, какие поля являются обязательными. Вы можете пропустить условие if - or else - в зависимости от того, по какому пути вы хотите работать. Это также облегчает понимание того, что вы читаете.
  3. Вы можете сделать это с помощью комментария. По моему опыту работы над долгосрочными проектами, комментарии устаревают. Люди не уверены в обновлении или удалении комментария, особенно если они не знают, почему он там. Бывают ситуации, когда подойдет только комментарий, но я использую их в крайнем случае.

Заключение

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

«Действительно, соотношение времени, затрачиваемого на чтение и на запись, намного превышает 10: 1. Мы постоянно читаем старый код в рамках усилий по написанию нового кода. … [Следовательно,] облегчая чтение, легче писать ».

Все, что может упростить чтение - и давайте пропустим некоторые из них - должно быть хорошо.

У меня нет чугунного правила, чтобы определить, когда создавать такую ​​переменную с хорошим именем. Мой подход на данный момент состоит в том, чтобы остановиться, когда я пишу какие-либо логические операторы, и подумать, могу ли я сделать свой код более понятным, сначала переместив результат в другую переменную.

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

Всего наилучшего,
Ник