Когда девять месяцев назад я написал для себя маленькую консольную утилиту, я и не подозревал, что вскоре она превратится в серьёзный и единственный в своём роде инструмент, которым будут пользоваться даже такие известные всем команды, как jQuery, Bootstrap, Angular. Сейчас, когда я пишу эту статью, у моего проекта на гитхабе 1010 звёздочек, и мне очень радостно думать о том, что так много людей смогли с помощью моей придумки сделать свою работу удобнее.
История этого проекта началась с моей личной боли.
Незадолго до этого момента я перевёлся из одной команды Яндекс.Карт в другую и постепенно вливался в разработку нового для меня продукта. Все было хорошо, новый проект мне нравился, но кодстайл, в котором писали ребята из моей новой команды, очень уж сильно отличался от того стиля кодирования, в котором писал я и ребята из моей прежней команды. Однажды меня даже посетила нелепая мысль, что кодстайл в этой группе писался в противоположность кодстайлу в прежней группе специально, чтобы запутать меня.
Например…
Однажды я закончил разрабатывать новый визуальный блок и отправил его на кодревью, чтобы ребята посмотрели его на предмет дефектов в логике. Вот так он тогда выглядел.
Вот в этом-то ревью меня и поджидало разочарование.
Представьте, я целую неделю делал новую форму фидбека, отлаживал, приводил код в порядок. Но первое же замечание, которое я получил в ревью — это было: “После function нет пробела”. И точно такое же ещё в 5-ти местах кода?!
Поймите меня правильно. Я разрабатывал продукт, старался. Придумал нетривиальную логику, в которой вообще не оказалось ошибок. Но ревью я не смог пройти только потому, что забыл поставить пробел после слова «function»?! Мне это не понравилось. Мне хотелось, чтобы ревьюеры обращали внимание на мой код, на его архитектуру, на дефекты в логике, а не на нарушения командного кодстайла.
Мне стало грустно. Потом было второе подобное ревью, и повторилась та же самая ситуация с пробелом после «function». Вот дался им этот пробел! И в тот момент я отчётливо понял, что продолжаться так дальше не может. Я разозлился.
Так и родился JavaScript Code Style, — сокращенно JSCS, — инструмент, который сообщает мне обо всех нарушениях кодстайла ещё до того, как я отправляю код на ревью. Долгое время в этой утилите было лишь одно правило, которое проверяло, есть ли пробел после “function”. И этого мне было достаточно, чтобы чувствовать себя счастливым. Если мне случалось снова забыть вставить этот злосчастный пробел, JSCS мне сообщал об этом перед каждым коммитом:
Какое-то время этой утилитой пользовался я один, ни с кем не делился. А зачем? Я решил свои проблемы и успокоился. Но вскоре выяснилось, что у многих моих коллег возникают такие же проблемы с кодстайлом. Только они не пробел после “function” забывали ставить, а, например, добавить перевод строки в конце файла. Я и поделился с ними.
JSCS начал распространяться внутри Яндекса. Он стал стремительно обрастать новыми правилами. Разные команды, разные кодстайлы — стали появляться новые интересные правила, например, запрет на неявное приведение типов (
Если спросить меня, что вызвало такой взрывной рост популярности этого проекта, я отвечу.
В первую очередь, подобного полноценного инструмента не существовало в тот момент, и я не уверен, что есть сейчас. Вторая причина заключается в том, что инструмент призван решить одну маленькую, всем понятную, актуальную для многих, задачу. И третья, на мой взгляд, очень важная причина — я смог сделать инструмент с простой и очевидной программной архитектурой. То есть, инструмент не пытается решать кучу разноплановых задач, он делает что-то одно, но делает это очень хорошо.
Почему не стали расширять jshint, ведь раньше jshint имел ряд правил по проверке стилистики кода?
Эти правила были неполны, хаотичны, и сами разработчики jshint’а хотели от них избавиться. Вот почему в репозитории JSCS появился появился тикет №102 где Майк (Mike Sherov) начал переносить правила проверки стиля из jshint в jscs. Сейчас в новой версии jshint’а нет ни одного правила проверки стилистики, и JSCS стал единственным полноценным инструментом, который решает эту задачу.
А ещё у проекта появилось еще два постоянных мейнтейнера. Ими оказались ребята, которые занимаются разработкой ядра jQuery – Mike Sherov (mikesherov) и Олег Гайдаренко (markelog), они разгребают огромное количество тикетов, которые приходят от пользователей. И те звездочки, которые заработал проект на гитхабе, их большая заслуга. Спасибо вам, ребята, большое!
Страница проекта на гитхабе: https://github.com/mdevils/node-jscs. На этой страницы описано более 60-ти правил, с помощью которых можно настроить валидацию кодстайла в проекте.
Приходите, пользуйтесь, вдруг и вам тоже понравится.
История этого проекта началась с моей личной боли.
Незадолго до этого момента я перевёлся из одной команды Яндекс.Карт в другую и постепенно вливался в разработку нового для меня продукта. Все было хорошо, новый проект мне нравился, но кодстайл, в котором писали ребята из моей новой команды, очень уж сильно отличался от того стиля кодирования, в котором писал я и ребята из моей прежней команды. Однажды меня даже посетила нелепая мысль, что кодстайл в этой группе писался в противоположность кодстайлу в прежней группе специально, чтобы запутать меня.
Например…
Однажды я закончил разрабатывать новый визуальный блок и отправил его на кодревью, чтобы ребята посмотрели его на предмет дефектов в логике. Вот так он тогда выглядел.
Вот в этом-то ревью меня и поджидало разочарование.
Представьте, я целую неделю делал новую форму фидбека, отлаживал, приводил код в порядок. Но первое же замечание, которое я получил в ревью — это было: “После function нет пробела”. И точно такое же ещё в 5-ти местах кода?!
Поймите меня правильно. Я разрабатывал продукт, старался. Придумал нетривиальную логику, в которой вообще не оказалось ошибок. Но ревью я не смог пройти только потому, что забыл поставить пробел после слова «function»?! Мне это не понравилось. Мне хотелось, чтобы ревьюеры обращали внимание на мой код, на его архитектуру, на дефекты в логике, а не на нарушения командного кодстайла.
Мне стало грустно. Потом было второе подобное ревью, и повторилась та же самая ситуация с пробелом после «function». Вот дался им этот пробел! И в тот момент я отчётливо понял, что продолжаться так дальше не может. Я разозлился.
Так и родился JavaScript Code Style, — сокращенно JSCS, — инструмент, который сообщает мне обо всех нарушениях кодстайла ещё до того, как я отправляю код на ревью. Долгое время в этой утилите было лишь одно правило, которое проверяло, есть ли пробел после “function”. И этого мне было достаточно, чтобы чувствовать себя счастливым. Если мне случалось снова забыть вставить этот злосчастный пробел, JSCS мне сообщал об этом перед каждым коммитом:
Какое-то время этой утилитой пользовался я один, ни с кем не делился. А зачем? Я решил свои проблемы и успокоился. Но вскоре выяснилось, что у многих моих коллег возникают такие же проблемы с кодстайлом. Только они не пробел после “function” забывали ставить, а, например, добавить перевод строки в конце файла. Я и поделился с ними.
JSCS начал распространяться внутри Яндекса. Он стал стремительно обрастать новыми правилами. Разные команды, разные кодстайлы — стали появляться новые интересные правила, например, запрет на неявное приведение типов (
!!x — плохо, Boolean(x) — хорошо). А немного погодя, я выложил JSCS на гитхаб. И тогда правила стали добавляться и внешними (относительно Яндекса) людьми. И вдруг посыпались звёздочки.Если спросить меня, что вызвало такой взрывной рост популярности этого проекта, я отвечу.
В первую очередь, подобного полноценного инструмента не существовало в тот момент, и я не уверен, что есть сейчас. Вторая причина заключается в том, что инструмент призван решить одну маленькую, всем понятную, актуальную для многих, задачу. И третья, на мой взгляд, очень важная причина — я смог сделать инструмент с простой и очевидной программной архитектурой. То есть, инструмент не пытается решать кучу разноплановых задач, он делает что-то одно, но делает это очень хорошо.
Почему не стали расширять jshint, ведь раньше jshint имел ряд правил по проверке стилистики кода?
Эти правила были неполны, хаотичны, и сами разработчики jshint’а хотели от них избавиться. Вот почему в репозитории JSCS появился появился тикет №102 где Майк (Mike Sherov) начал переносить правила проверки стиля из jshint в jscs. Сейчас в новой версии jshint’а нет ни одного правила проверки стилистики, и JSCS стал единственным полноценным инструментом, который решает эту задачу.
А ещё у проекта появилось еще два постоянных мейнтейнера. Ими оказались ребята, которые занимаются разработкой ядра jQuery – Mike Sherov (mikesherov) и Олег Гайдаренко (markelog), они разгребают огромное количество тикетов, которые приходят от пользователей. И те звездочки, которые заработал проект на гитхабе, их большая заслуга. Спасибо вам, ребята, большое!
Страница проекта на гитхабе: https://github.com/mdevils/node-jscs. На этой страницы описано более 60-ти правил, с помощью которых можно настроить валидацию кодстайла в проекте.
Приходите, пользуйтесь, вдруг и вам тоже понравится.
