JSLint - игнорировать разделы кода - PullRequest
33 голосов
/ 23 августа 2010

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

  /*jlsint xxx:true/false*/

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

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

Например:

for(L=(117.>

вызывает это сообщение:

Problem at line 1 character 57: A trailing decimal point can be confused with a dot '117.

Конечно, я знаю, что могу очистить код, но он исходит от обфускатора, и я действительно не хочу чистить запутанный код!

Итак, есть лиспособ заставить JSLint полностью игнорировать растянутый код?

Мне известен этот запрос JSLint: контрольные комментарии (выборочное игнорирование) , но на него не было ответа.

Ответы [ 2 ]

12 голосов
/ 19 февраля 2014

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

/* jshint ignore:start */
// Code here will be linted with ignored by JSHint.
/* jshint ignore:end */

Документацию можно найти здесь и прокрутите вниз до раздела "директивы".

1 голос
/ 12 марта 2015

Вы можете добавить это самостоятельно в JSLint, если хотите, хотя это граничит со Злом.

Вот один быстрый и грязный способ с текущей версией:

Маршрут, по которому я собираюсь идтизаключается в захвате блока switch функции token для комментариев в стиле /*.Это в строке 1276 в настоящее время :

case '/*':
    for (;;) {
        i = source_row.search(lx);
...

Давайте изменим это, чтобы искать комментарии, которые выглядят как /*ignore:true */ в отдельной строке (хотя технически половина true может быть где угоднона линии в этом случае, хотя /*ignore:false */ строка имеет , чтобы быть на одной строке, поэтому давайте притворимся, что это верно для обоих).

Пример плохой, код с ошибками lint:

function spam()
{
    var sand = "sand";
/*ignore:true */
    var spud = "spud";
/*ignore:false */
    window.console.log(sand);
}

Если мы найдем /*ignore:true */, давайте пропустим строки, пока не найдем строку с /*ignore:false */ с /*ignore:... в качестве самых первых символов в строке .Пока это ложное утверждение в строке само по себе, мы игнорируем все .

case '/*':
    // Opening /* has already been sliced.
    if (source_row.startsWith("ignore:true"))    {
        do  {
            if (console.log) { console.log(source_row) };
        } while (next_line() && !source_row.trim().startsWith("/*ignore:false"));
    }   else    {
        // Put in the code that was originally there
    }
    break;

Это ужасно, но, похоже, работает.

Теперь это может вызвать проблемы.Например, если у вас есть объявление var в разделе, который вы игнорируете, и будете использовать его позже, JSLint_Hacked пожалуется, что myVar was used before it was defined. Пример:

/*jslint white:true, sloppy:true, browser:true */
function spam()
{
    var sand = "spam";
/*ignore:true */
    var spud = "spud";
/*ignore:false */
    window.console.log(sand + spud);
}

Так что подобные вещи могут стать неприятными.

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

Мне нужно больше времени проводить внутри JSLint, чтобы узнать, как она на самом деле работает, но функция next_line() кажется неразрушающей.То есть вы могли бы (и должны) справиться с этим в функции do_jslint() с помощью "настоящих" директив стиля /*jslint ignore:true */, но тогда вам придется обрабатывать побочные эффекты при вызове функции advance().Взлом, который я здесь использую, был намного проще, но он также намного более уродлив.

...