05.04.2009

JSLint

Валидировали, валидировали, да не вывалидировали.

Думаю, многие пробовали программу JSLint — валидатор для проверки корректности JavaScript-кода. Однако блиц-опрос знакомых разработчиков показал, что почти все пользуются им лишь изредка, и едва ли кто задумывался о том, чтобы сделать JSLint неотъемлемой частью процесса разработки.

JSLint — сверхценный инструмент в арсенале JavaScript-разработчика. Должен сказать, что с тех пор, как я стал систематически им пользоваться, мой код стал значительно лучше. Ведь помимо отлова мелких багов и опечаток, JSLint способствует написанию стройного, слаженного, читабельного кода.

Главное — не перегибать палку

Не стоит принимать отчет JSLint как истину в последней инстанции и сразу бросаться править код. Это всего лишь рекомендация, поэтому нужно включить у себя в голове thinking mode и по каждой ошибке в отчете решить самому — согласиться с JSLint или нет. Благодаря тому, что у JSLint есть множество опций, позволяющих указать какие ошибки искать, а какие игнорировать, этот инструмент можно легко настроить на свой вкус.

Варианты использования

1. Самый простой — пойти на сайт JSLint и скопипейстить свой код в форму валидации.

2. Виджеты JSLint Widget, JSLint Multi widget, JSLint Dashboard widget for Mac OS X.

Можно драгндропнуть JS-файл или целую папку в окошко виджета, и получить отчет JSLint. В настройках виджета есть полный комплект опций JSLint.

JSLint Widget

Чем больше объем JS-кода, тем больше хочется интеграции со средой разработки (IDE). Также для крупных проектов желательно сделать валидацию рутинной операцией, выполняющейся автоматически, например, на этапе сборки и упаковки JS-кода.

3. В Aptana есть встроенный JSLint, который изначально выключен. Включить можно в настройках: Preferences → Aptana → Editors → JavaScript → Validation. После этого код будет валидироваться по мере того, как вы его печатаете.

JSLint в Аптане

К сожалению, у JSLint в Аптане нет опций.

4. Плагин к Eclipse. В начале этого года компания RockstarApps выпустила JSLint Eclipse Plugin. Опции все есть, но нет возможности указать predefined global variables, что, конечно, обломно.

5. Rhino и Windows Script Host. На одном из проектов мы используем Rhino для запуска JSLint. Написали скрипт, который обходит все проектные JS-файлы, для каждого из них вызывает JSLint и формирует общий отчет — очень удобно! Пожалуй, надо будет написать отдельный пост про это :-)

JSLint продолжает развиваться. Следить за обновлениями можно в группе JSLint, куда часто пишет сам Крокфорд, автор JSLint.

А вы валидируете свой JavaScript-код?

23 комментария:

Leonya комментирует...

А бездумно пользоваться им и не получится. Если, например, на большом codebase броситься исправлять "==" на "===" везде где хочет JSLint, мы словим тучу тонких багов. Поэтому линтить нужно с самого начала, и тогда волосы будут мягкие и шелковистые.

DenisX комментирует...

я — нет

shabunc комментирует...

пока нет. а если и будем, то вполне может статься и не jlint

Степан Резников комментирует...

2DenisX: А ты попробуй, вдруг понравится :)

2shabunc: Если не JSLint, то что? Чем JSLint не устраивает, чего не хватает? Я вот знаю еще есть JavaScript Lint (спасибо Вегеду за наводку). Они вроде как идут своим путем, отдельно от Крокфорда, но суть та же. Опций у них меньше, поэтому туго с настройкой под свои нужды.

smalex комментирует...

Степа, валидатор и прочее это конечно очень круто, но люди давно уже придумали отличный валидатор называется компилятор.
В случае с JS считаю что большие проекты нужно писать с помощью GWT.

alpha комментирует...

Smalex, GWT, конечно же, занял свою нишу. Но она так и осталась достаточно небольшой. И уж точно разговор, что большие js-проекты нужно писать с помощью GWT, выглядит, мягко говоря, преувеличением. Тем более, когда ты говоришь об этом js-программистам. :)

smalex комментирует...

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

главное настоящим js-программистам не остаться за бортом, когда через несколько лет будут появляться настоящие gwt программисты которые будут херачить код со страшной скоростью, он у них будет написан с помощью тестов и багов почти не будет :-)

alpha комментирует...

Поверь, помимо GWT, в js-мире происходит очень многое :) И недостатка в средствах нет. И уж на совсем чистом js уже давно никто не пишет. Да и во многих вещах чистый js гораздо лучше, компактнее и понятнее чем строго типизированная java (например, замыкания).
Не зря многие js считают самым недооцененным языком.

Еще не совсем понял, что ты имел ввиду под затрудненным рефакторингом? И что где плывет?

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

smalex комментирует...

Честно говоря я не собирался дисскутировать и сравнивать js и gwt.
Для себя я выбор сделал, а убеждать кого-то мне нет нужды.

Нормальный рефакторинг это то что можно делать с java кодом в IDEA. Автоматический рефакторинг для JS тоже есть, но в нем намного скромнее функционал.

alpha комментирует...

Ты сделал этот выбор, потому что ты программируещь на java и не занимаешься фронтэндом.

Почитал что сейчас написано на странице Google Web Toolkit. Это просто чушь, особенно:

Создание веб-приложений – это утомительный процесс, в течение которого возникает много ошибок. 90% времени уходит на обработку особенностей браузеров, а недостаточная универсальность JavaScript делает совместное использование, тестирование и повторное использование компонентов AJAX сложным и ненадежным.

Как кто-то выражался, правда немного на другую тему - это написано людьми, которые не знают JavaScript для людей, которые не знают JavaScript.

smalex комментирует...

Может быть вы просто с гуглом о разных проектах судите? Ты о проекте в 5000 строк и 1-3 коммитера. А гугл о 50000 строк и 10 коммитеров? :-)

alpha комментирует...

Я говорю о том, что если у программиста 90% времени уходит на обработку особенностей браузеров (а с учетом использования современных js-фрэймворков это более чем странно), то у него явно что-то в консерватории и GWT ему не поможет. Независимо от кол-ва строк и числа коммитеров.

Если человек не умеет писать повторно используемый код, то он его и на GWT его не напишет.

Если человек не умеет писать тесты, то GWT не научит его это делать.

smalex комментирует...

Пока ты не видишь какие плюсы даёт использование строго типизированного и компилируемого языка ты не поймёшь зачем они это сделали.

Сергей Чикуенок комментирует...

Как у вас тут весело :) Вставлю свои 5 копеек.
1. JSLint'ом не пользуюсь, пока не вижу острой необходимости в этом. В больших скриптах приходится экономить не некоторых конструкциях в угоду компактности и скорости кода. В этом случае варнинги больше отвлекают, чем помогают. Зато комментарии пишу всегда :)

2. Спор smalex и alpha. Смалекс, ты не учитываешь несколько фактов. Посмотрим на примере абстрактного сайта.

Java — серверный язык, работающий на одной тачке с четко известными (и наращиваемыми) характеристиками, для которого объем кода не имеет значения.

JavaScript — клиентский язык, работающий на тысячах (в пределах одного сайта) машин с ХЗ какой конфигурацией и ХЗ какой версией ХЗ какого браузера. Объем кода в данном случае является критическим фактором.

Для GWT объем результатирующего пожатого JS-кода в 1МБ — это норма. Даже несмотря на то, что из его реально используется 5-10%. Ну и вопрос в профайлинге кода остается открытым: насколько легко можно заменить стандартные компоненты на низкоуровневые аналоги для конкретного браузера?

smalex комментирует...

Ребята, вы просто не в курсе что такое GWT, какие операции происходят, как генерится код, как происходит кеширование,
как происходит lazy подгрузка кода.
Нечего тогда приводить аргументы которые ни о чём.

1 мегабайт по-умолчанию это абсурд, у нас код большой админки занимает мегабайт.

Сергей Чикуенок комментирует...

Да я в курсе, что такое GWT и нисколько не умаляю его достоинств. Любую технологию надо применять с умом.

1 мегабайт по-умолчанию это абсурд, у нас код большой админки занимает мегабайт.

А я не говорю, что 1 МБ — по умолчанию. Это как раз норма тех самых больших проектов, которые ты предлагаешь писать на GWT. :)

smalex комментирует...

Ну хорошо хоть так. :-)

Я просто GWT уже пару лет юзаю и знаю из чего эта штука сделала, и как её постоянно совершенствуют.
Профайлеры там тоже кстати есть.
И есть возможность включить произвольный код на javascript для native штук.

alpha комментирует...

Smalex, я могу сказать тебе аналогичную вещь, без обид - ты просто не в курсе как делается фронтэнд проекта. Что помимо js есть еще и другие составляющие. Пока ты не поймешь чем декларативное лучше в данном случае императивного, ты тоже не поймешь зачем не нужно все делать на gwt :)

smalex комментирует...

Согласитесь что фронэнд бывает разный?
Я ни разу не призывал зарыть js и всем писать на gwt. Просто для больших проектов написанных полностью только на js планка сложности кода ниже чем можно было написать на gwt. Именно из-за того что сложнее работать с нетипизированным языком. А для новых людей которые не провели годы в трахах с браузерами и говорить не стоит насколько gwt проще использовать.

Прикиньте сколько понадобилось бы времени чтобы написать тулзу сходную по возможностям?

http://gwt.google.com/samples/Showcase/Showcase.html

alpha комментирует...

Ну посмотри, например, на ExtJS.
Там и посложнее вещи, и выглядит, оно прямо скажем, посимпатичнее. И написано на чистом js. Или тебе кажется, что все к чему прикасается google, является априори самым лучшим средством?

smalex комментирует...

> Ну посмотри, например, на ExtJS.
> Там и посложнее вещи, и выглядит, оно
> прямо скажем, посимпатичнее. И написано
> на чистом js.

это всего лишь ещё одна библиотека компонентов, я думаю подобные вещи существовали почти сразу после изобретения js

> Или тебе кажется, что все к чему
> прикасается google, является априори
> самым лучшим средством?

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

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

alpha комментирует...

Ты невнимательно смотрел - это не просто библиотека компонентов.

Ну а по поводу того, что google всегда делает лучше всех. Есть и него неудачные проекты, которые провалились. Тебе назвать?

alexander комментирует...

>>>А вы валидируете свой JavaScript-код?

Да, в несколько этапов:

на CI-сервере:

У нас перед заливкой кода в trunk CI-сервер прогоняет тесты. Среди них есть и прогонка js через jslint. Я делал это на ant+rhino. Подробнее можно почитать тут: http://habrahabr.ru/blogs/client_side_optimization/45480/

В редакторе кода:
1. Так как в основном сижу на маке, то я использую лучший редактор в мире (textmate :), я использую javascript tools bundle для него. При сохранении файла автоматически проганяется валидация.

2. Иногда я работаю на ubuntu, и тогда пишу все в vim. Валидирую js в точно так, как описано тут.

3. Должен заметить, что javascript syntax checking в ide IntelliJ idea версии 8 и выше позволяет обходиться без jslint'а. И js2-mode для emacs - тоже.