FullStack Software Developer
7,2
рейтинг
21 апреля 2014 в 16:23

Разработка → JSCS: JavaScript Code Style

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

История этого проекта началась с моей личной боли.

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

Например…

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



Вот в этом-то ревью меня и поджидало разочарование.

Представьте, я целую неделю делал новую форму фидбека, отлаживал, приводил код в порядок. Но первое же замечание, которое я получил в ревью — это было: “После 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-ти правил, с помощью которых можно настроить валидацию кодстайла в проекте.

Приходите, пользуйтесь, вдруг и вам тоже понравится.
Дулин Марат @mdevils
карма
153,7
рейтинг 7,2
FullStack Software Developer
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Разработка

Комментарии (118)

  • +3
    Чем JSLint не устроил-то?
    • +12
      Все просто: JSLint про ошибки, JSCS про код-стайл.
      • +3
        Не могли бы вы привести больше примеров? Пока смутно понимаю, в чём принципиальное отличие. И в JSLint, и в вашем проекте можно настроить, например, необходимость фигурных скобок у if .. else, однако это не «ошибка», как вы пишете, а именно стиль оформления кода.
        • 0
          JSLint не покрывает требований по кодстайлу наших проектов. Да и не развивается он. Если бы и развивался, то архитектура в JSLint настолько ужасно, что контрибьютить — это последнее, что хочется.
          • –2
            Ну так может вы приведете список стилевых правил, которые поддерживает сабж? :)

            А то получается как в анекдоте:

            — Я сделал изобретение, позволяющее видеть сквозь стены!
            — Но оно уже давно существует.
            — Как же оно называется?
            — Окно.
            • +4
              Их более 60-ти и все они описаны по ссылке, которую я привел в конце статьи: github.com/mdevils/node-jscs
      • +1
        1) JSLint — не только про ошибки.
        2) Вы привели только один пример недостатка кода, который обнаруживает сабж: отсутствие пробела между function и скобкой. JSLint это отлавливает.
        • 0
          Цель моего вопроса была как раз в том, чтобы понять, какие уникальные настройки вы предоставляете в JSCS.
          Предположим, есть проект, который использует JSLint. Как мне сконфигурировать(и для каких кейсов, что самое важное) JSCS, чтобы они не конфликтовали(ведь насколько я понял, у них есть дублирующий функционал)?
        • +1
          1) А с помощью утюга можно приготовить яичницу, например. Но вот испечь пирог будет проблемно.
          2) Вы правы, пример с пробелом не очень-то наглядный, но идея понятна и всегда же можно перейти по урлу и мелько пробежаться глазами. Не поленитесь. Настроек очень много.
      • +2
        Более того, поддержка JSLint имеется практически у всех IDE и редакторов кода. Недостатки кода подсвечиваются во время написания, а не при запуске консольной команды.
        • 0
          Чуть выше ответ.
        • +2


          Дело времени.
          • +1
            Будем ждать для PHPStorm / WebStorm. Или уже есть?
            • +1
              Пока нет, но есть задача, за которую можно проголосовать: youtrack.jetbrains.com/issue/WEB-10591
              • 0
                Уже есть плагин.
  • +16
    Время выполнения !!x — 12мс, Boolean(x) — 310. С одной стороны это — на миллионе операций, а с другой — разница больше чем на порядок. Отличный код стайл.
    Скрытый текст
    (function(){
      var t = +new Date(), x = true;
      for( var i = 1000000;--i;){
        x = Boolean(x);
      }
      console.log(-(t-(t=new Date())));
      for( var i = 1000000;--i;){
        x = !!x;
      }
      console.log(-(t-(t=new Date())));
    
    })();
    

    • +5
      Не знаю как вы, но я пишу код для людей, мучаться должны роботы и переделать код как им нужно при минификации ;)
      • +11
        Не знаю как вы, но я согласен с Zibx. Я пишу приведение к булеву через двойное отрицание не из-за количества символов, и не понимаю, чем плоха эта запись. Прочитать !!x не сложнее, чем Boolean(x), тем более работает быстрее.
        • +4
          Мне как и вам прочитать не сложно. Любой не посвященный в JS скажет, что !!x — читается как магия; Boolean(x) — все понятно ;)
          • +12
            Для непосвящённого в JS прототипное наследование — магия, например, что ж теперь, его выкидывать? Для тех, кто программирует на Си# странно, что замыкание создаётся только на уровне функций (а for, например, новую область не создаёт), так давайте не будем пользоваться замыкамиями! Они, кстати, сами по себе для многих — магия!
            • +3
              Поэтому не стоит делать из языка элитарное сообщество, ограниченное трехметровым порогом входа. Не забывайте, что есть ряд людей, которые не пишут фуллтайм на JS, но им приходится с ним работать.
            • 0
              Не совсем понял, что вы имели в виду под «замыкание создаётся только на уровне функций (а for, например, новую область не создаёт)» — можно пример кода для ясности?
              • +1
                Классика:
                for (var i = 0; i < 3; i++) {
                    setTimeout(function () {
                        alert(i);
                    }, 100);
                }
                
                • –3
                  Я так и думал, но проверил следующим куском кода и он отработал ожидаемым образом, выведя последовательно числа от 0 до 4:

                  var data = [];
                  
                  for(var idx = 0; idx < 5; idx++) {
                      var curr = function() { alert(idx); };
                      data.push(curr);
                  }
                  
                  for(var idx = 0; idx < 5; idx++) {
                      data[idx]();
                  }
                  

                  Не могу понять, в чем разница между вашим кодом и моим?
                  • +3
                    у вас во втором цикле переменная тоже называется idx, показывается ее значение
                    • +1
                      Спасибо, разобрался!
                  • +2
                    Здесь есть тонкий момент, во втором цикле вы на самом деле используете ту же самую переменную idx, что и в первом случае, попробуйте переименовать её в напрмер в jdx и все станет на свои места:

                    	var data = [];
                    
                    	for(var idx = 0; idx < 5; idx++) {
                    		var curr = function() { alert(idx); };
                    		data.push(curr);
                    	}
                    
                    	for(var jdx = 0; jdx < 5; jdx++) {
                    		data[jdx]();
                    	}
                    
                  • –2
                    Ваш код синхронный. Мой асинхронный.
                    • +2
                      Это чуть ли не худший ответ, который вы могли дать. Он не просто неправильный — он может создать у новичка ложное ощущение правильного понимания причины проблемы.
                      • +1
                        Я ответил вполне на конкретный вопрос: «Не могу понять, в чем разница между вашим кодом и моим?». Не знаю стало ли проще если я бы ответил, что в JS область видимости через var создает только функция, поэтому в следующем тике event loop значение переменной будет 3 и эта переменная будет общая для всех безымянных «замыканий» аргумента setTimeout.
                        • +1
                          Нет, проще бы не стало. Так как новый ответ снова как минимум некорректен в плане формулировки:
                          1) var никаких областей видимости не создает (с функцией или без)
                          2) то, будет ли функция вызываться асинхронно в другом тике или нет с обсуждаемой проблеме на самом деле не имеет никакого отношения
            • 0
              Прототипное наследование — одна из основных особенностей языка, а использование двойного отрицания для неявного приведения к булеву это использование фич языка не по назначению, побочное свойство некоторых особенностей.
          • 0
            Ну, любая поддержка кода требует понимания языка, на котором он написан. Я думаю, как bolk сказал ниже, проблема в том, что качество программистов падает, и людям становится слишком лениво разбираться в тонкостях работы с языком. Порой даже попадаются индивидумы, которые могут писать селекторы с использованием jQuery, но вытащить элемент по id на нативном JS не могут. Грустно всё это…
          • +1
            Вот уж не знаю, по моему все довольно очевидно, такой код вполне нормально работает в си/с++
          • –1
            Когда я первый раз встретился с ~~x, то тоже сначала растерялся, а ведь удобно.
            • 0
              Смотря для каких целей.
              Я предпочитаю, например, каноничное "| 0".
              • 0
                Спасибо)
        • +1
          Да это просто качество программистов падает. В языке разобраться лениво, поэтому писать можно только «не смущающими новичка конструкциями».
        • +4
          В данном случае я не соглашусь с собой. Не вникал в поведение Boolean без new. Был уверен что это фабрики и что поведение может в итоге ожидаться такое, которое не смогут оптимизировать роботы. Но в яндексе при сборке кода Boolean без new скорее всего и превратится в !!.. То есть скорость исполнения будет та же. У скорости ввода есть две стороны. Обычно скорость написания кода упирается не в скорость печати. Новичкам и тем кто не знаком с js понятнее запись Boolean. С другой стороны я был уверен что абсолютно все кто касается js в яндексе среди ночи смогут рассказать всё про автоматическое приведение типов.

          Да и статья о другом, думаю эту тулзу можно настроить в обратную сторону, что бы она ругалась когда вместо!!! стоит Boolean :).
          Интереснее причина такого кодстайла где в js после function нужен пробел. Очень похоже на портированный PEP8.
        • +1
          Сложнее прочитать. Не вникая в тонкости неявного приведения типов запись кажется семантически бессмысленной (двойное отрицание аргумента равносильно аргументу в булевой логике, а! булевый оператор), поведение в граничных случаях не очевидно. В общем, обычный хак. Если скорость выполнения важна, то согласно правилам хорошего тона его нужно дополнять комментарием типа // fast convert to boolean, а если не важна, то просто его не использовать.
    • 0
      Попробуйте для подобных сравнений jsperf использовать — очень удобно.
      jsperf.com/double-negative-vs-boolean

      Кстати, мне тоже больше нравится!!! х, по сравнению с Boolean(x). Читается легче.
      • +1
        Отличный сервис, использую. Но когда для себя замеряю попугаев — быстрее нажать F12 чем заполнять все их поля.
    • +1
      Ну верно, ваш код стайл просто восхитителен.
      Boolean(x) === false — читаемее, хоть запись и получается длиннее.
      Всякие !!x, и уж точно побитовые операции на вроде вашей +new Date() или всякие ~array.indexOf(x) стоит использовать только в больших циклах, где такая экономия на спичках имеет хоть какой-то смысл.
      • +11
        Это звучит как «да ну ваше наследование через цепочку прототипов, я подключу CoffeeScript и буду писать классы».
        • +1
          Если честно, я не понял при чем здесь прототипы и классы. Разговор вообще о другом.
          • +8
            Речь о том, что логическое отрицание(!) или побитовое отрицание(~) — это просто и понятно. Это есть почти во всех языках программирования. Не знать этого довольно-таки странно для программиста. Исходя из вашего поста выше, вы пишете так:

            if (Boolean(arr.length) === false) {
              ...
            }
            

            вместо

            if (!arr.length) {
              ...
            }
            

            верно?
            • –5
              Вы кажется перегибаете, любой вменяемый программист будет писать !arr.length
              • +10
                Тогда почему !arr.length — является «нормальным» приведением к булеву, а !!arr.length — нет?
              • –2
                Вменяемый вообще напишет arr.length === 0, если он хочет проверить не пустой ли массив.
            • +10
              Я обычно пишу:

              if (arr.length === 0) {
                ...
              }
              

              • 0
                Да, мне, кстати, с недавних пор тоже стало нравиться писать так. Вообще, как по мне, практика с явным определением типов — штука правильная и хорошо дисциплинирует. Но другое дело, когда мы хотим проверить параметр объекта, возможно оно false, 0 или вовсе undefined, вот тут я все же использую if (obj.param) {}
                • 0
                  Для меня 0 и undefined — это совершенно разные вещи и в одном условии я оба сразу не проверяю. Нет кейсов.
                  • 0
                    Конечно разные. В данном случае я рассматривал 0 как упрощенный вариант false в качестве ответа от сервера. Но так же сервер и вовсе может не установить в качестве ответа ничего. А когда мы знаем, что, возможное значение — число, пусть даже 0, то это совсем другой разговор. Так что все это частные случаи.
                • +2
                  undefined вот таким словом лучше не писать никогда. undefined — не константа, его можно от скуки переопределить. === void 0 или typeof, но при typeof производится не бесплатная операция сравнения со строкой (хотя может тут работает оптимизация глобального места где хранятся все строки). Иногда ещё 'param' in obj пригождается.
                  • –1
                    Мне всегда казалось, может быть наивно, что сравнение итога typeof оптимизировано в движке. Правда, не то чтобы я читал исходники V8 или IonMonkey.
                    • 0
                      Это в общем- то и не нужно.

                      Достаточно посмотреть к примеру на тот asm код который v8 генерирует.

                      Нет желания проверять, но почти уверен что все эти сравнение будут иметь одинаковый результат. JIT он не дурак и это его работа такие вещи оптимизировать.
      • +1
        Или в функциях, которые могут позвать из циклов. Или цикл может оказаться вложенным. Ещё забавно наблюдать как функцию мэппинга объявляют в цикле. Но я полностью согласен с тем что ресурсотерпящие вещи лучше писать читаемыми.
        • 0
          Мне кажется вы лукавите. Не знаю как там у вас, но я всегда знаю, какая функция чем может быть запущена, и окажется ли она в цикле. А если мы говорим про какие-то действительно монструозные вещи, на вроде библиотек, когда и правда не ясно, что будет делать другой разработчик с вашим кодом — то тогда уж точно разницы нет — время выполнения полезного кода будет выше, чем любая экономия.
          • +1
            Я говорю про функциональный подход. Когда в функции мэппинга делают ещё мэппинг. Тут уже на 1000 иттерациях может оказаться заметна разница. Библиотеки я как раз по этой причине избегаю почти все и использую microjs если есть конкретная задача, которая точно уже решена другими. Как наглядный пример такого подхода я обычно привожу конструкцию вида $('#el1').height(). Есть случаи когда достаточно сделать document.getElementById('el1').clientHeight. И вот в этом случае я прошу пройти по стеку того что делает жквери, что бы в итоге вызвать эту конструкцию. Но это важно в основном при отрисовке больших списков данных или когда мы пишем веб-приложение и весомая часть модели живёт в браузере. В случае если нам надо повесить событие на клик кнопки logout — тут действительно можно сделать это чем угодно. Но при этом событие mousemove использовать обёрнутое любой библиотекой — всё равно крайне не желательно, если мы хотим сделать плавную анимацию. Что-то я разошелся, оптимизация у меня — больная тема. :)
      • +3
        Boolean(x) === false
        Зачем? Неужели так читаемее?
        • –1
          Я вам больше скажу, в таких местах даже читаемее использовать Йода-стайл на вроде false === Boolean(x)
          Только не нужно кидаться тухлыми помидорами, не попробовав на практике такой подход. Это мы тут с вами снипеты в 2 строки разбираем, на реальном же коде особенности оформления уже играют большую роль в понимании.
          • +2
            «Йода-стайл», как вы его назвали, родился вовсе не из читаемости. Соглашение «константа слева» спасает от ситуации, когда программист пропускает одно равно и получает if (a = false) вместо if (a == false). В вашем же случае «false === Boolean(x)» это соглашение лишнее, да и вообще вся конструкция должна умереть.
            • –1
              Не сочтите за грубость, но вы же мне просто глаза открыли. Тем более, что про указанное вами соглашение можно не беспокоиться в рамках JS, так как if (x = 2) {} вызывает ошибку. Я же не заставляю никого писать так, как нравится мне, и как пишет команда автора из Яндекса, а у них-то наверное больше аргументов на счет явного приведения типов.
              • +1
                > …можно не беспокоиться в рамках JS, так как if (x = 2) {} вызывает ошибку.

                О чём это вы? if (foo = bar) успешно работает и используется в JS.
                Например:

                if (found = str.match(foo)) { bar = found[1]; … }
                • +3
                  Вот теперь можно констатировать, что я, кажется, сошел с ума. Я серьезно. Просто вот сейчас я не могу объяснить, как я такую ахинею мог написать, и как я так пришел к тому, к чему пришел. Стыдоба.
    • 0
      Дело скорее всего не в производительности, а в однозначности поведения. Чтобы код отрабатывал максимально одинаково на всех существующих известных, неизвестных и теоретически возможных платформах…
      • 0
        От этого спасут только тесты. Я вот был уверен что Boolean возвращает не примитив, а объект как в случае с new Boolean(false). И у меня есть уже немного опыта js, и потому я проверил и теперь знаю, а те кто делают код ревью могут не знать такой тонкости.
        Проверить объект это или примитив можно присвоив свойства объекта, а потом взяв его.
    • 0
      Микробенчмаркинг зло. Он показывает не цифры скорости какие-то цифры. JIT браузера очень интересно оптимизирует код.
      Пропустите код выше через V8 со специальными флагами посмотрите на ASM код который получится. Будете удивлены)
  • +6
    А нет в планах пойти дальше и не просто выводить ошибки, а делать авто форматирование кода? Пиши как хочешь, а хук на pre-commit приводит весь код к единому код стайлу.

    P.S. Сам пробовал jsbeautifier и esformatter, увы оба обладают своими недостатками, последний так совсем коверкает исходный файл.
    • –1
      В планах этого нет. Цель проекта в том, чтобы помочь привыкнуть и с помощью CI — контролировать.
      • +4
        Очень жаль.
        • 0
          И мне тоже. Новая команда — и сразу обучение новому стилю, хотя логика от этого не меняется. В PHPStorm видел при коммите возможность переформатировать код автоматически, только вроде это к php относится и, если и к JS, то изменения типа !!x -> Boolean(x) не делает.
    • 0
      Есть проект, который может форматировать код, количество настроек там правда пока невелико.

      github.com/jedmao/codepainter
  • +17
    Открывая статью надеялся, что это не про другой JSLint, а про автоматическое форматирование кода — настроил свои правила, и при чекауте получаешь JS-код в своём любимом стиле, а при коммите он переформатируется в принятый в команде.
    Зачем мне сообщение о забытом пробеле и облом коммита? Компьютер железный — пусть он и расставляет (не)нужные пробелы.
    • +1
      Это был бы идеальный инструмент!
    • 0
      WebStorm же это умеет делать. Один раз настроил правила и всё ок.
      • 0
        не умеет(на сколько я знаю). Он умеет форматировать код так, как вам нужно.
        Но тут человек хочет получить Boolean(x), а видеть !!x, например
        • 0
          [deleted]
    • +1
      Тогда нужно и обратное преобразование делать (при пуллиге кода из репозитория). Иначе смысл теряется.
  • +4
    1. Выбрать одно лучшее IDE (мы, например, выбрали IDEA)
    2. Использовать дефолтные настройки и не лезть со своим Code Style (мы просто жмем Ctrl + Alt + L, срабатывает авто-форматирование и стиль у всех один)
    • –1
      3. Continuous Integration.

      Тут и начинаются проблемы.
      • +9
        Какие?
    • +5
      меня бы очень расстроило если бы кто-то начал мне говорить какую IDE использовать
      • +1
        Одну IDE использовать совсем не обязательно, есть тот же editorconfig, например.
      • –1
        Неужели в вашей любомй IDE нет авто-форматирования кода?
        • +1
          может и есть, но в комментарии, на который я отвечал, предлагали всей командой перейти на одну IDE
          • +2
            Ммм, да, я почему-то прочитал его как «настроить свои IDE единообразно, согласно code style команды и пользоваться авто-форматированием». Удивляюсь теперь, как так вышло.
  • +1
    После function нет пробела

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

    И, может быть, имеет смысл написать средство форматирования кода и использовать его повсеместно?
    • 0
      И, может быть, имеет смысл написать средство форматирования кода и использовать его повсеместно?


      Дописать clang-format, например, сейчас там уже есть минимальный задел на js. Тем более, такая вещь нужна всему Яндексу.
  • –3
    А для виндузятников экзешник?
    • НЛО прилетело и опубликовало эту надпись здесь
      • 0
        Звиняйте, не разобрался, думал скрипт для баша…
  • +6
    Вот смотрю я на эту форму фидбека и не могу придумать, какая там может быть нетривиальная логика внутри. Поделитесь, что она делает хоть, кроме очевидной отправки фидбека?
    • –3
      Рейтинг там примеру со звёздами, который можно попариться при наведении мышки красиво анимировать. Форма может увеличивается при наборе текста. Анимация при добавлении какая-нибудь.

      Всегда легко посмотреть на что-нибудь вроде твиттера и хмыкнуть «ха, бложик на 140 знаков».
      • 0
        Так я же не хмыкаю. Наоборот, хочу постичь и приобщиться. Тем более, что фраза «нетривиальная логика» подразумевает не просто анимацию звездочек
  • +2
    А не было варианта просто настроить инспекции в каком-нибудь ВебШторме? Или том же Виме/Емаксе, я ими сам не пользуюсь, но раз они осиливают подсветку, значит с синтаксическими конструкциями работать в принципе можно.
    • 0
      Если честно, размер проекта на гитхабе поистине пугает. я бы ограничился примитивным скриптом, выдающим ошибки в типичном формате компиляторов <path>:<line>:<message>. Vim (syntactic), Emacs (compile/recompile, flymake) и ST (из коробки) прекрасно понимаю такой формат и позволяют прыгать к исходникам и выделать строки с ошибками.
  • +3
    Очень хорошо, что осведомили. Кабы карма Ваша не была и без того заплюсована мною — беспременно заплюсовал бы её сегодня.

    А не то, видите ли, я до сих пор сидел на JSHint 2.x, потому что произошедшие в 3.x перемены (отказ от проверки стиля) ну никак не мог принять.

    Конечно, теперь (когда есть отдельный стилепроверщик) — это неплохо. Есть куда убежать с JSHintовской проверки стиля.

    (Хорошо бы кто-нибудь #138 пофиксил, конечно; но и без того очень, очень неплохо.)
  • +5
    мне одному кажется, что комментаторы не поняли сути JSCS?
  • 0
    Кода довольно много, что бы пролистать, поэтому проще спросить — проводится ли семантический анализ, посроение AST? Если нет, почему недостаточно регулярных выражений, на которые способно большинство полноценных текстовых редакторов, ну или sed awk? Какого рода парсинг проводится, если не секрет?
    • 0
      Парсинг и построение AST с помощью esprima.
      • 0
        Вызывает уважение. Тогда по обмену опытом, мой сейчас любимый язык Go включает такого рода утилиту форматирования в коробочной поставке. Конфигурация не предусматривается, поскольку полагается что весь код на Go должен быть написан единообразно. Зато присутствует зачаточная возможность символьной трансформации, то есть например можно задать правило 2*x -> x+x
  • –9
    Классика жанра:
    image
  • +1
    Почему бы не сделать описание правил форматирования на основе BNF?
  • –7
    Что-то я не понял.
    Есть команда, в которой принят некий стиль. Там же есть, видимо, специально обученный человек, который высматривает пробелы и грепает восклицательные знаки. Сам расставлять пробелы он не умеет, просто рефьюзит коммит. Вы (автор статьи) написали утилиту, которая заменяет этого человека. И команде ничего не говорили… Мне это как-то дико. Или в команде тоже используется какой-то инструмент, но вы решили написать свой? Или в команде у каждого свои костыли имеются? Я работал в разных командах и что-то не могу представить вашу ситуацию.
    Спрашиваю потому, что уже не первый раз рассказы о том, как работает Яндекс, вводят меня в недоумение.
    • +2
      В каких-то странных командах вы работали.
      Процедуру код ревью себе представляете? Я, на всякий случай расскажу. Вы пишете код, ваши коллеги его смотрят, пишут замечания, вы исправляете (ну или обосновываете, что написали как надо) код в соответствии с замечаниями, отправляете на повторное ревью и т.д…
      То есть не нужен специальный человек для этого.
      А автору статьи было сложно привыкнуть к новому для него стилю кода, и для помощи себе он написал утилиту, которая оказалась полезной множеству людей.
      То что общепринятые практики разработки ПО вводят вас в недоумение, то у меня для вас плохие новости.
      • 0
        Во-первых.
        Мне всегда попадались люди, которые обнаруживали ошибки типа «это не заработает на python 2.3», «здесь лучше использовать другую структуру данных», «у нас принято писать комментарии на английском языке»… К пробелам и деталям типа «типов в языках со слабой типизацией» либо не привязывались, либо проверяли линтерами и прочими инструментами.
        Во-вторых.
        Мне попадались команды, где разработанные инструменты тут же становились общим достоянием. Макросы к редакторам, анализаторы логов, и даже форматировалки исходников. Все эти вещи разрабатывались совместно. И мне действительно трудно представить противоположную ситуацию. Почему человек вынужден делать для себя очевидный инструмент? Почему, сделав его, он не предлагает его команде? Ждёт, когда каждый сделает себе свой? Я действительно не понимаю логику такого поведения.
        • 0
          К пробелам и деталям типа «типов в языках со слабой типизацией» либо не привязывались, .

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

          Вы ведь понимаете, что инструмент написали потому что подходящего не было?

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

          Статью читали? В статье явно написано, что с коллегами поделился. А теперь и со всеми желающими за пределами компании (что гораздо важнее, как мне кажется).

          Вы выглядите приятным, разумным человеком, но в первом комментарии какую-то ерунду написали, честное слово.
  • +2
    Недавно наткнулся на ESLint. Проект позиционирует себя как модульная альтернатива jslint/jshint, где каждый может легко добавлять свои правила. К сожалению пока руки не дошли попробовать, но было бы интересно сравнить и узнать мнение тех кто пользовался
  • +2
    Уже много месяцев пользуюсь вашей разработкой в виде grunt-плагина grunt-jscs-checker во всех проектах. Ужасно доволен, спасибо вам огромное!
    Не прочитал все коментарии, возможно уже спрашивали. Планируется ли сделать удобный интерфейс для генерации конфига jscs? Чтобы не читать весь ридми с последующей копипастой, а прощелкивать слайды, а в конце копировать конфиг?
    • 0
      Нет, простого интерфейса для конфигурации нет. Но если вы разработаете, мы будем счастливы его принять и развивать.
      • +1
        Ок, попробую набросать прототип на gh-pages в форке к вашему репу. Вопрос в том, будут ли его поддерживать, при добавлении новых правил, чтобы держать в актуальном состоянии…
        • 0
          Если будет удобно и понятно реализовано, то пользователи смогут контрибьютить с учетом этой страницы.
  • 0
    Мимо.
  • +1
    youtrack.jetbrains.com/issue/WEB-10591
    Поддержите предложение для JetBrains по внедрению этого плагина в их IDE.
  • 0
    Судя по камментам мало кто читал гитхаб и мало кто понял зачем данная итилита. Печально.
  • 0
    У нас в компании царят формат-фашизм и граммар-нацизм, поэтому JSCS наряду с JSHint стоит на хуках в репозиториях.
    Нестильный код не пройдёт!

    Спасибо за такую потрясающую утилиту.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.