Согласованность экономит время и энергию разработчиков
Учитывайте пробелы.
В языках, где он является семантическим, он влияет на программу, и то, что является «лучшим» или «худшим» пробелом, может отличить работающую программу от неисправной. Существует четкий правильный ответ на вопрос, как следует применять пробелы.
В языках, где это исключительно эстетический вопрос, вопрос в том, как лучше форматировать код.
Любая часть программного обеспечения, которая является исключительно вопросом мнения, является питательной средой для бессмысленных споров.
Нет правильного ответа; мода меняется каждый сезон («Разве они не прекрасны, июнь?», «Сказочный Гарри, я люблю запятые в конце»).
Некоторые языки избегают этого, имея четко определенные правила и инструменты для их применения, такие как 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
, и вы ее полностью поймете.