JSLint

[hf3]

http://www.jslint.com/

Попробовал вставаить туда небольшой свой скритик строчек на 40 и привести в соответсвие. Стало страшно…

Я и хтмлному валидатору относится с большим недоверием… но тут…

А вы готовы писать строгий JavaScrip t ?

[s0rr0w]

Бред какой-то. Эта поделка явно не ECMA совместимая.

[hf3]

Ну вот новый Jquery проходит эту поделку)) Так что не все так просто...

[Great Rash]

Не понимаю как это jQuery может проходить эту поделку ибо вот такой код, "валидацию" не проходит:

(function() {
	var x = 0;
	return {
		init: function() {
			return x;
		}
	}
})();

Причем ошибки выдает очень странные, например жалуется на отсутствие ";" на 7 строке. Однако ECMA позволяет считать перенос (\r\n) как завершение строки. Опять же ошибка "no global variable specified" какая-то странная. Быть такого не может, чтоб без глобальной переменной нельзя было б обойтись.

Опять же, тот же jQuery весь построен на анонимной функции...

[s0rr0w]

Причем ошибки выдает очень странные, например жалуется на отсутствие ";" на 7 строке. Однако ECMA позволяет считать перенос (\r\n) как завершение строки. Опять же ошибка "no global variable specified" какая-то странная. Быть такого не может, чтоб без глобальной переменной нельзя было б обойтись.

Опять же, тот же jQuery весь построен на анонимной функции...

Аналогичные претензии. Чуваки явно не читали спеку ECMA.

[hf3]

Ну чуваки сильно перегибают палку. Это безсомнения.

Ну и цель как я понял у них была не создать валидатор, а скорее определить хоть какие то рамки и правила написания JSа. Так как JS позволяет много вольностей.

Таже самая точка с запятой...

Цели то правильные, но методы…

[rash]

Аналогичные претензии. Чуваки явно не читали спеку ECMA.

А разве эти требования противоречат ECMA?

[SelenIT]

Если я ничего не путаю, нынешняя спека ECMA (5-я редакция) во многом появилась благодаря тому самому чуваку (Крокфорду), который уже десяток лет ведет эту поделку. И да, с некоторыми вещами в прошлых редакциях он (о5 же если я ничего не путаю) был не совсем согласен...

А еще этот чувак кое в чем соперничает с Чаком и Онотолеем...

[rash]

Если я ничего не путаю, нынешняя спека ECMA (5-я редакция) во многом появилась благодаря тому самому чуваку (Крокфорду), который уже десяток лет ведет эту поделку. И да, с некоторыми вещами в прошлых редакциях он (о5 же если я ничего не путаю) был не совсем согласен...

А еще этот чувак кое в чем соперничает с Чаком и Онотолеем...

Ну, по мнению отметившихся здесь товарищей, тем не менее, спецификацию он не читал

[s0rr0w]

А разве эти требования противоречат ECMA?

Требуется исправлять то, что разрешено на то, что разрешено. Где логика? Не ешь кашу ложкой, ешь ее чайной ложкой.

[SelenIT]

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

[Great Rash]

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

[SelenIT]

Вероятно, потому, что в JS глобальные переменные могут создаваться неявно (и неочевидно), и такие неявные засорения глобального объекта — однозначное зло (с этим Крокфорд не спорит). Вот что он сам пишет по поводу:

Ideally, an application, library, component, or widget defines only a single global variable. That variable should be an object which contains and is the root namespace for all of your stuff.

[s0rr0w]

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

Не поня-я-я-я-ятно... © Бабушка провинциального актера.

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

Да и спека постоянно развивается. Понятия "разрешено всегда" не существует без обязательной приписки "в таких-то версиях языка".

Вероятно, потому, что в JS глобальные переменные могут создаваться неявно (и неочевидно), и такие неявные засорения глобального объекта — однозначное зло (с этим Крокфорд не спорит). Вот что он сам пишет по поводу:

А ему в голову ни разу не приходило, что глобальных объектов может быть несколько? Это звучит странно, правда, но это уже так и есть. Любой глобальный JS объект может быть локальным в некой объектной модели.

[SelenIT]

Почему мы должны делать какие-то вещи для минификации в ущерб той же читабельности кода?

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

глобальных объектов может быть несколько?

Тем более нужно стараться, чтоб нечаянно не засорить их все

[rash]

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

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

[s0rr0w]

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

Мне глубоко плевать на Крокфорда в данном вопросе.

Особенно в таком примере

if ( x ) { try { if(x != undefined ) { x='{}'; } else { x='}{'; }; } catch(e) {}; };

После линтования получилось

var x; if ( x ) { try { if( x !== undefined ) { x='{}'; } else { x='}{'; } } catch(e) {} }

Тем более нужно стараться, чтоб нечаянно не засорить их все

Это нереально по правилам языка.

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

Есть спецификация скрипта. Движок или делает все по спеке, или не делает. Тепличные условия - абсолютное следование спецификации, а не сомнительным советам Гуру.