Валидировали, валидировали, да не вывалидировали.
Думаю, многие пробовали программу 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.
Чем больше объем JS-кода, тем больше хочется интеграции со средой разработки (IDE). Также для крупных проектов желательно сделать валидацию рутинной операцией, выполняющейся автоматически, например, на этапе сборки и упаковки JS-кода.
3. В Aptana есть встроенный JSLint, который изначально выключен. Включить можно в настройках: Preferences → Aptana → Editors → JavaScript → Validation. После этого код будет валидироваться по мере того, как вы его печатаете.
К сожалению, у JSLint в Аптане нет опций.
4. Плагин к Eclipse. В начале этого года компания RockstarApps выпустила JSLint Eclipse Plugin. Опции все есть, но нет возможности указать predefined global variables, что, конечно, обломно.
5. Rhino и Windows Script Host. На одном из проектов мы используем Rhino для запуска JSLint. Написали скрипт, который обходит все проектные JS-файлы, для каждого из них вызывает JSLint и формирует общий отчет — очень удобно! Пожалуй, надо будет написать отдельный пост про это :-)
JSLint продолжает развиваться. Следить за обновлениями можно в группе JSLint, куда часто пишет сам Крокфорд, автор JSLint.
А вы валидируете свой JavaScript-код?
23 комментария:
А бездумно пользоваться им и не получится. Если, например, на большом codebase броситься исправлять "==" на "===" везде где хочет JSLint, мы словим тучу тонких багов. Поэтому линтить нужно с самого начала, и тогда волосы будут мягкие и шелковистые.
я — нет
пока нет. а если и будем, то вполне может статься и не jlint
2DenisX: А ты попробуй, вдруг понравится :)
2shabunc: Если не JSLint, то что? Чем JSLint не устраивает, чего не хватает? Я вот знаю еще есть JavaScript Lint (спасибо Вегеду за наводку). Они вроде как идут своим путем, отдельно от Крокфорда, но суть та же. Опций у них меньше, поэтому туго с настройкой под свои нужды.
Степа, валидатор и прочее это конечно очень круто, но люди давно уже придумали отличный валидатор называется компилятор.
В случае с JS считаю что большие проекты нужно писать с помощью GWT.
Smalex, GWT, конечно же, занял свою нишу. Но она так и осталась достаточно небольшой. И уж точно разговор, что большие js-проекты нужно писать с помощью GWT, выглядит, мягко говоря, преувеличением. Тем более, когда ты говоришь об этом js-программистам. :)
в выборе средств надо учитывать много факторов и тем более нельзя рассуждать, что раз наши деды писали на нетипизируемом языке где всё постоянно плывёт, и рефакоринг затруднён, то и мы должны следовать их заветам.
главное настоящим js-программистам не остаться за бортом, когда через несколько лет будут появляться настоящие gwt программисты которые будут херачить код со страшной скоростью, он у них будет написан с помощью тестов и багов почти не будет :-)
Поверь, помимо GWT, в js-мире происходит очень многое :) И недостатка в средствах нет. И уж на совсем чистом js уже давно никто не пишет. Да и во многих вещах чистый js гораздо лучше, компактнее и понятнее чем строго типизированная java (например, замыкания).
Не зря многие js считают самым недооцененным языком.
Еще не совсем понял, что ты имел ввиду под затрудненным рефакторингом? И что где плывет?
Я помню, ты несколько лет назад тоже самое говорил про настоящих gwt-программистов, а воз и ныне там. Не подходит это средство для нормального фронтэнда. И кроме административных интерфейсов, я так ничего стоящего, сделанного на GWT, так и не увидел.
Честно говоря я не собирался дисскутировать и сравнивать js и gwt.
Для себя я выбор сделал, а убеждать кого-то мне нет нужды.
Нормальный рефакторинг это то что можно делать с java кодом в IDEA. Автоматический рефакторинг для JS тоже есть, но в нем намного скромнее функционал.
Ты сделал этот выбор, потому что ты программируещь на java и не занимаешься фронтэндом.
Почитал что сейчас написано на странице Google Web Toolkit. Это просто чушь, особенно:
Создание веб-приложений – это утомительный процесс, в течение которого возникает много ошибок. 90% времени уходит на обработку особенностей браузеров, а недостаточная универсальность JavaScript делает совместное использование, тестирование и повторное использование компонентов AJAX сложным и ненадежным.
Как кто-то выражался, правда немного на другую тему - это написано людьми, которые не знают JavaScript для людей, которые не знают JavaScript.
Может быть вы просто с гуглом о разных проектах судите? Ты о проекте в 5000 строк и 1-3 коммитера. А гугл о 50000 строк и 10 коммитеров? :-)
Я говорю о том, что если у программиста 90% времени уходит на обработку особенностей браузеров (а с учетом использования современных js-фрэймворков это более чем странно), то у него явно что-то в консерватории и GWT ему не поможет. Независимо от кол-ва строк и числа коммитеров.
Если человек не умеет писать повторно используемый код, то он его и на GWT его не напишет.
Если человек не умеет писать тесты, то GWT не научит его это делать.
Пока ты не видишь какие плюсы даёт использование строго типизированного и компилируемого языка ты не поймёшь зачем они это сделали.
Как у вас тут весело :) Вставлю свои 5 копеек.
1. JSLint'ом не пользуюсь, пока не вижу острой необходимости в этом. В больших скриптах приходится экономить не некоторых конструкциях в угоду компактности и скорости кода. В этом случае варнинги больше отвлекают, чем помогают. Зато комментарии пишу всегда :)
2. Спор smalex и alpha. Смалекс, ты не учитываешь несколько фактов. Посмотрим на примере абстрактного сайта.
Java — серверный язык, работающий на одной тачке с четко известными (и наращиваемыми) характеристиками, для которого объем кода не имеет значения.
JavaScript — клиентский язык, работающий на тысячах (в пределах одного сайта) машин с ХЗ какой конфигурацией и ХЗ какой версией ХЗ какого браузера. Объем кода в данном случае является критическим фактором.
Для GWT объем результатирующего пожатого JS-кода в 1МБ — это норма. Даже несмотря на то, что из его реально используется 5-10%. Ну и вопрос в профайлинге кода остается открытым: насколько легко можно заменить стандартные компоненты на низкоуровневые аналоги для конкретного браузера?
Ребята, вы просто не в курсе что такое GWT, какие операции происходят, как генерится код, как происходит кеширование,
как происходит lazy подгрузка кода.
Нечего тогда приводить аргументы которые ни о чём.
1 мегабайт по-умолчанию это абсурд, у нас код большой админки занимает мегабайт.
Да я в курсе, что такое GWT и нисколько не умаляю его достоинств. Любую технологию надо применять с умом.
1 мегабайт по-умолчанию это абсурд, у нас код большой админки занимает мегабайт.
А я не говорю, что 1 МБ — по умолчанию. Это как раз норма тех самых больших проектов, которые ты предлагаешь писать на GWT. :)
Ну хорошо хоть так. :-)
Я просто GWT уже пару лет юзаю и знаю из чего эта штука сделала, и как её постоянно совершенствуют.
Профайлеры там тоже кстати есть.
И есть возможность включить произвольный код на javascript для native штук.
Smalex, я могу сказать тебе аналогичную вещь, без обид - ты просто не в курсе как делается фронтэнд проекта. Что помимо js есть еще и другие составляющие. Пока ты не поймешь чем декларативное лучше в данном случае императивного, ты тоже не поймешь зачем не нужно все делать на gwt :)
Согласитесь что фронэнд бывает разный?
Я ни разу не призывал зарыть js и всем писать на gwt. Просто для больших проектов написанных полностью только на js планка сложности кода ниже чем можно было написать на gwt. Именно из-за того что сложнее работать с нетипизированным языком. А для новых людей которые не провели годы в трахах с браузерами и говорить не стоит насколько gwt проще использовать.
Прикиньте сколько понадобилось бы времени чтобы написать тулзу сходную по возможностям?
http://gwt.google.com/samples/Showcase/Showcase.html
Ну посмотри, например, на ExtJS.
Там и посложнее вещи, и выглядит, оно прямо скажем, посимпатичнее. И написано на чистом js. Или тебе кажется, что все к чему прикасается google, является априори самым лучшим средством?
> Ну посмотри, например, на ExtJS.
> Там и посложнее вещи, и выглядит, оно
> прямо скажем, посимпатичнее. И написано
> на чистом js.
это всего лишь ещё одна библиотека компонентов, я думаю подобные вещи существовали почти сразу после изобретения js
> Или тебе кажется, что все к чему
> прикасается google, является априори
> самым лучшим средством?
во-первых я сужу не только по первым впечатлениям, а после долговременного использования.
а во-вторых я думаю ты не далек от правды. пока если гугл что-то делает, то он делает лучше всех.
Ты невнимательно смотрел - это не просто библиотека компонентов.
Ну а по поводу того, что google всегда делает лучше всех. Есть и него неудачные проекты, которые провалились. Тебе назвать?
>>>А вы валидируете свой 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 - тоже.
Отправить комментарий