ESlint потрясающий. Это позволяет нам писать красиво отформатированный код Javascript и предотвращать множество синтаксических и семантических ошибок. Излишне говорить, что вы можете подготовить свое рабочее пространство, просто запустив eslint --init. Библиотека сгенерирует конфигурацию по умолчанию, которая подходит большинству разработчиков, не так ли? Что ж, я думаю, что есть по крайней мере одно правило, которое следует настроить, если вы хотите сделать свой код более чистым и более удобным в обслуживании.
Код похож на книгу. Читаем его вниз, шаг за шагом следуя заявленным командам. Тем не менее, есть некоторые отличия. Авторам не нужно объявлять каждое слово, которое используется в романе, во введении. Но вот что такое программирование.
Мы не можем ссылаться на song перед назначением, это привело бы к ReferenceError. Но если бы мы это сделали, мы бы не узнали об этом, пока кто-нибудь не попробовал сыграть в нее. Javascript не является компилируемым языком, поэтому большинство ошибок остаются незамеченными до тех пор, пока выполнение не дойдет до точки неисправности. Вот и наступает момент, когда приходит ESlint! Есть полезное правило под названием no-use-before-define, которое активировано по умолчанию. Он проверяет, была ли уже определена переменная, на которую вы ссылаетесь.
Как видите, ESlint не позволяет Javascript иметь обратный эффект. Но есть и темная сторона. Что я имею в виду? Давайте посмотрим на другой пример.
Этот код правильный, потому что функции в Javascript имеют ту же область видимости, что и объявление с ключевым словом var. Вы можете обратиться к одному из них, даже если он определен под вызывающим кодом, и так оно и должно быть. Когда вы объявляете функции сверху вниз по их использованию, легко читать код и понимать поток. Более того, этот подход рекомендован «Чистым кодом» Мартина.
Но вот сюрприз. Правило ESlint no-use-before-define не позволяет нам вызывать функции, объявленные после его использования. Мы получим ту же ошибку, что и при обращении к необъявленному song. Если мы хотим исправить эту ошибку, мы можем реорганизовать наш код и изменить порядок функций.
Этого хочет от нас ESlint. Этот фрагмент кода более понятен, чем предыдущий? Я сомневаюсь. И я думаю, что вы тоже. Представьте, что кто-то просматривает наш пул-реквест. Если кто-то хотел понять, что происходит, ему нужно было бы прокрутить страницу вниз, чтобы сначала проверить точку входа. После этого они, вероятно, будут просматривать функции друг друга снизу вверх. Видимо, неудобно. Но, к сожалению, это политика конфигурации ESlint по умолчанию.
В любом случае, какое решение? Что ж, мы могли бы просто деактивировать no-use-before-define правило. Но это также привело бы к возможным ошибкам с переменными. Надеюсь, есть способ получше.
Вот и все! Теперь ESlint позволяет нам упорядочивать функции, как нам нравится. Правило также можно отключить для классов (да, проверяет и классы). Более подробную информацию вы можете найти по этой ссылке.
Заключение
Я надеюсь, что вы узнали что-то новое о ESlint. Я считаю, что предпочтительная конфигурация может быть не такой «предпочтительной» в реальном мире. Итак, не стоит слишком полагаться на свое мнение о том, что правильно. Даже мой. Возможно, вы думаете, что я ошибаюсь. Если это так, я хотел бы обсудить статью в разделе комментариев. Спасибо за чтение!
