JSLint — The JavaScript Verifier

Шеф дал задание пожать все JavaScript-файлы моего текущего проекта и применить к ним обфускацию (запутывание кода программы). Я всё сделал, и проект перестал работать :(

ObfuscatingОказалось, что после проведения указанных мероприятий работа алгоритма может быть нарушена. Самая простая причина — чрезмерная лояльность JavaScript, ведь разделителем команд может быть не только точка с запятой (как в Си или в PHP), но и конец строки — и если две такие стоящие рядом строки «слепить», будет ошибка.

Поскольку на глаз такие места найти трудно в большом количестве файлов, я нашёл полезный он-лайн инструмент JSLint — верификатор кода, указывающий на недочеты ваших скриптов.

Сразу скажу, что я использовал примерно 20% его возможностей :) Я повыключал все галочки, а их много: от проверки на «Strict whitespace» (почему у тебя не 8 пробелов?) до «Disallow ++ and — -» (а вдруг у тебя выражение a+++b в коде встретится?). Я просто вставлял содержимое очередного файла и смотрел, что мне инкреминируют.

Сразу обнаружил несколько минусов, которые смутили:

1. если написать что-то вроде

return some_user_function();

то получаем ошибку «отсутствие new перед вызовом конструктора».

2. C with() не дружим. «Ждали стейтмент, а нашли with, плохо»

3. Прямым текстом написали «eval is evil» («eval суть зло», перевод с английского мой). Я его тоже не люблю, но подобный коммент удивил.

В принципе, все эти моменты описаны в документации, но к чему эти драконовские меры в ежовых рукавицах, я не понял:

JavaScript allows var definitions to occur anywhere within a function. JSLint is more strict.

Зато после исправления большинства рекомендаций мои пожатые файлы стали работать как раньше, только в размере уменьшились в 5-10 раз. Q.E.D.

Основные моменты, который пришлось править:

  • несколько пропущенных точек с запятой после выражений;
  • на всякий случай внял подсказкам и позаключал блоки даже с одним оператором в фигурные скобки.
Понравились такие замечания:
  • я использую функцию parseInt, так вот мне было сказано, что нехорошо пропускать второй параметр, который указывает систему счисления для «парсения инта» (radix);
  • затесался у меня switch() с одним-единственным case и дефолтом — так вот, я получил рекомендацию заменить его на условный оператор if().
После верификации кода JSLint’ом можно применить обфускатор, например, packer — не тешу себя надеждами, что код становится невзламываемым, но выглядит страшно :) И размер скукожился — значит, пользователь будет рад.

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn



12 коментарів

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.

Интересные факты, есть что почерпнуть — в фаворитс.Вот еще интересная разработка обфускатора на PHP http://www.webnext.ru/blog/200... (в разделе софт можно скачать), но что меня удивило (может проглючило) больше всего, так то что он «раздувает» скрипты. Попробовал запаковать Prototype 1.6, в результате получил +40 лишних Кб.Пакер, представленный в последних строках статьи очень помог — Prototype стал 125 → 89 Кб.Аптаной пользоваться пытался, но в силу слабости моего компа, эта кроссплатформенный редактор работал не с должной скоростью.Спасибо за статью и комментарии.

JSLint меня не вдохновил — не получилось запаковать кусок кода

А ты пробовал гвозди отвёрткой вкручивать?:) JSLint — это верификатор JavaScript, а не пакер; он указывает на недочеты кода (то, что ты назвал «отказами»:)) А вот «edwards packer» — это обфускатор и пакер, и ссылка на него имеется в предпоследней строке статьи.

JSLint меня не вдохновил: (не получилось запаковать кусок кода. Лучше уж юзать edwards packer http://dean.edwards.name/packe.../ отказов меньше. Но это чисто мое мнение.

Також різні попередження про неправильний чи ненадійний код видаються прямо під час редагування в мабуть одному з найпотужніших JavaScript редакторів Aptana.

На сайте packer’a (обфускатора, указанного в конце статьи) есть плагин для Aptana, так что вообще прелесть получается:)

Згадав ще одну статтю (в основному про стиснення, але все ж близьку до теми): http://www.andrewdupont.net/20.../Там рекомундують Dojo ShrinkSafe для «all those damned semicolons»:)

JSLint:

var o = {test: 1, func: function () {return 1;}}

Error: Problem at line 1 character 43: Missing semicolon.Статья как раз про то, что такие места можно отлавливать JSLint’ом, а только потом применять обфускацию.

2Alex: Ну в даних прикладах можна просто орієнтуватись на

var ...

, який треба закінчувати ; тоді не важливо чи

var i;

— чи

var f=function...;

і т. д.

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

var f = function(){return 1;}

или

var o = {test: 1, func: function(){return 1;}}

обфускатор выдаст дохлый скрипт. А пральный для него код будет

var f = function(){return 1;};

и

var o = {test: 1, func: function(){return 1;}};

Аптану посмотрим, спасибо.GZip никто не мешает применить (особенно после такой оптимизации), только тогда в некоторых броузерах js-файлы не закэшируются.

2Сергей: часто ж поєднують.Є ще одна свіжа стаття по темі: How to Boost Your JavaScript and CSS Performance.

А не проще для уменьшения размера пользоваться gzip?

Також різні попередження про неправильний чи ненадійний код видаються прямо під час редагування в мабуть одному з найпотужніших JavaScript редакторів Aptana.

Підписатись на коментарі