Согласованность экономит время и энергию разработчиков

Учитывайте пробелы.

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

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

Любая часть программного обеспечения, которая является исключительно вопросом мнения, является питательной средой для бессмысленных споров.

Нет правильного ответа; мода меняется каждый сезон («Разве они не прекрасны, июнь?», «Сказочный Гарри, я люблю запятые в конце»).

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

Другие (почему это всегда вы, JavaScript?) имеют легко настраиваемые движки линтинга, которые обеспечивают согласованность в проекте (например, они могут влиять только на подмножество файлов, и вы можете использовать встроенные объявления для отключения определенных правил, которые вроде как нарушает правила).

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

  • Дуглас Крокфорд создал JSLint в… прошлом. Это было очень самоуверенно, и это мнение принадлежало Дугласу Крокфорду. Это было нормально, пока вы соглашались с ним.
  • Не все так делали, поэтому JSHint был создан (Дугласом Крокфордом) из JSLint с добавленным поведением принятия конфигурации. Это делает его значительно более востребованным продуктом за счет снижения достоверности (возможно, вы отключили некоторые действительно полезные правила).
  • Затем был создан ESLint, в основу которого легла конфигурация и плагины. Эта расширяемость позволила ESLint очень дешево поддерживать нишевые случаи для новых библиотек; просто добавьте плагин, изменение версии не требуется.
  • Наконец, в 2016 году был создан Prettier. Это не линтер, но его можно использовать как плагин к линтеру. Он касается только форматирования кода, в то время как линтер выделяет другие проблемы, такие как недоступный код.

Prettier существует, чтобы «остановить все текущие споры о стилях», что он и делает, предоставляя некоторые самоуверенные правила.

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

Я чувствую, что здесь упущена возможность; Я потратил всего несколько часов впустую, споря о табуляциях и пробелах, и я потратил очень много часов на просмотр кода.

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

Более быстрое развитие

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

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

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

Чистый код не самый ценный при активной разработке. Это действительно сияет при чтении кода.

Быстрый обзор

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

Я обнаружил, что два раза читаю код; как часть запроса на вытягивание или «в состоянии покоя», когда я разрабатываю.

Код «в покое» немного проще. Есть большая вероятность, что кто-то из вашей команды уже видел это раньше и может объяснить, если вы застряли. Есть большая вероятность, что это знакомый шаблон, который вы видели в коде раньше.

Код «Pull Request» сложнее. Вероятно, это будет новый функционал. Это может быть новый шаблон, написанный настолько ясно, насколько ваш коллега может собраться после 9 дней подряд кофеинового запоя и последующего краха. Это сопряжено с риском, который невозможен для кода «в состоянии покоя»; это может привести к изменению, которое негативно повлияет на ваш продукт.

Единственная лучшая причина для использования инструмента форматирования кода — упростить проверку кода.

Выбор правил

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

Установив все настраиваемые правила, чтобы свести к минимуму их влияние на diff.

Любое улучшение производительности, не связанное с узким местом, — иллюзия.

Рассмотрим правило «конечной запятой»:

const items = [
  1,
  2
]

Если вы хотите добавить элемент в этот массив, diff покажет две строки:

-  2
+  2,
+  3

Однако с включенными конечными запятыми:

const items = [
  1,
  2,
]

То же изменение делает меньший, более четкий diff:

+  3,

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

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

Для каждого правила настройте его так, чтобы минимизировать разницу

Что, если я соло-разработчик?

Вы не.

Я говорю это не только потому, что по статистике большинство инженеров будут работать в командах.

У вас когда-нибудь был неприятный опыт повторного просмотра кода, который вы написали 6 месяцев/2 года/3 работы назад?

Или вы когда-нибудь отказывались от стороннего проекта, чтобы вернуться к нему спустя полвека?

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

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

Восстановить необходимый настрой бывает невозможно.

Прошлое — это другая страна; в прошлом ты другой человек

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

Как все может быть лучше?

Есть проблемы с текущими инструментами форматирования в JavaScript. Prettier будет разделять длинные операторы, чтобы удовлетворить ограничение на количество символов, а не для удобочитаемости.

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

Я бы хотел, чтобы инструмент, который при одном и том же AST всегда возвращал один и тот же источник. Prettier в настоящее время не будет работать, поскольку он пытается соблюдать разрывы строк во входных данных.

Удобочитаемость существует в спектре; читаемый код можно сделать менее читаемым (путем запутывания имен переменных и т. д.).

Читабельность также субъективна. Я нахожу короткие имена переменных, такие как x, легко читаемыми, в то время как большинству инженеров, с которыми я работал, нравятся описательные имена. Я пытался объяснить, что x означает some generic thing, doesn't matter, но они поняли это — я просто ненавижу называть вещи.

Тем не менее, есть четкие шаблоны, которые, как мы можем согласиться, улучшают читабельность нашего кода. Не втискивайте слишком много в одну строку. Избегайте чрезмерного пространства. Минимизируйте свои различия!

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

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