Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 61
Баг рипорт мэйнтейнерам оптимизатора. У ECMAscript абсолютно четкая грамматика.
Ловцу бага от этого будет не легче :)
Людям, которые пишут оптимизаторы, очень полезны подобные фидбэки. Они могут просто не знать о подобных проблемах.
Вносите свою лепту в инструменты, которыми пользуетесь.
Пример из моей жизни: Я в 98 году написал класс, который куда только не пастили. Года через 3 пришел баг репорт, о том, что класс не верно себя ведёт с аутлуком. Всех изменений — добавить \r. В сети на форумах нашел пару десятков веток, как обойти этот баг.
MiKXMan, Вы уверены, что вместо того, чтобы автор добавил строчку в BNF, нужно сидеть тихо и клепать воркараунды? Вы, уверены, что авторы продуктов, которыми Вы пользуетесь не заслуживают чести получить репорт, что бы улучшить своё детище? Вы уверены, в продукте, который не получает или не исправляет репортов?
Да, конечно написать толковый репорт — час времени. Или каждый должен ловить свои баги?
Вносите свою лепту в инструменты, которыми пользуетесь.
Пример из моей жизни: Я в 98 году написал класс, который куда только не пастили. Года через 3 пришел баг репорт, о том, что класс не верно себя ведёт с аутлуком. Всех изменений — добавить \r. В сети на форумах нашел пару десятков веток, как обойти этот баг.
MiKXMan, Вы уверены, что вместо того, чтобы автор добавил строчку в BNF, нужно сидеть тихо и клепать воркараунды? Вы, уверены, что авторы продуктов, которыми Вы пользуетесь не заслуживают чести получить репорт, что бы улучшить своё детище? Вы уверены, в продукте, который не получает или не исправляет репортов?
Да, конечно написать толковый репорт — час времени. Или каждый должен ловить свои баги?
Не может. Или это катастрофически сломанный минимизатор, не поддерживающий JS, зачем тогда его использовать.
Давайте еще по IE6 определять, какой JS хороший, а какой плохой.
Давайте еще по IE6 определять, какой JS хороший, а какой плохой.
Хороший перевод хорошей статьи. Но коль тема у нас оптимизация процесса проверки качества кода. То хочу добавить, что JSDOC аннотации + google closure compiler позволяют многие типы ошибок, начиная с синтаксиса и проверкой типов, и заканчивая необъявленные переменными или недоступным кодом.
Помимо jslint и jshint очень советую использовать github.com/mdevils/node-jscs.
Даешь холивар «таб vs пробелы»! И больная же тема.
Да разве только «таб vs пробелы»?!
Тут холиваров не на один месяц статей:
— Пробел между аргументами и выражением
— Кавычки
— Открывающая скобка
…
Тут холиваров не на один месяц статей:
— Пробел между аргументами и выражением
— Кавычки
— Открывающая скобка
…
Для меня двух пробелов мало, а четырёх — много.
Использую поэтому три пробела.
Использую поэтому три пробела.
Хорошо бы такие требования свести в таблицу (для аргументации в мелких рабочих группах, почему так лучше или так), а также дополнить все правила аргументациями, почему лучше так, а не иначе. И наконец, перечислить кодоформматоры — что они умеют и для каких языков (будет болльшая таблица — фичи по горизонтали, языки по вертикали, форматоры в ячейках).
* Например, когда лучше пробелы, а когда — табы, об этом много писали в статьях ранее.
* Почему лучше одиночные кавычки в JS, а двойные — в HTML — потому что так меньше конфликтов при записи одного в другом, а двойные в HTML традиционны.
* Почему лучше запятые перед объявлением — потому что сразу и на одном месте видно, что означает очередная строка, не глядя в её конец.
* Всегда точка с запятой — потому что бывают ошибки при сцеплении строк с переносом, когда конец одной — без точки с запятой, а начало следующей — скобка.
* Например, когда лучше пробелы, а когда — табы, об этом много писали в статьях ранее.
* Почему лучше одиночные кавычки в JS, а двойные — в HTML — потому что так меньше конфликтов при записи одного в другом, а двойные в HTML традиционны.
* Почему лучше запятые перед объявлением — потому что сразу и на одном месте видно, что означает очередная строка, не глядя в её конец.
* Всегда точка с запятой — потому что бывают ошибки при сцеплении строк с переносом, когда конец одной — без точки с запятой, а начало следующей — скобка.
Вы пишете об использовании слов «is», «set», «get» в именах функций, что библиотека jQuery «без особого мнения».
На самом же деле библиотека jQuery построена таким образом, что употребление этих слов в именах функций исключается. Один и тот же метод объекта может совершать и get (например,«$('div.hh').css('color')»), и set (например, «$('div.hh').css('color', '#7FA0B0')»).
И это правильное построение. Если бы вместо этого существовали два разные методаgetCSS() и setCSS(), то программисту пришлось бы вдвое больше вспоминать и вдвое больше набирать каждый раз (имя метода стало бы вдвое длиннее).
На самом же деле библиотека jQuery построена таким образом, что употребление этих слов в именах функций исключается. Один и тот же метод объекта может совершать и get (например,
И это правильное построение. Если бы вместо этого существовали два разные метода
Два важных уточнения:
1) На самом деле не «Вы пишете», а «Otto Kekäläinen пишет». Я видел, что передо мною перевод, так что это моё выражение — просто оговорка.
2) На самом деле «вдвое больше вспоминать» не только за счёт роста длины имени метода в два раза, но также и за счёт увеличения числа самих методов вдвое же. Может быть, вернее было бы мне сообщить, что «вчетверо больше вспоминать» приходится, но уверенности в этом у меня нет.
1) На самом деле не «Вы пишете», а «Otto Kekäläinen пишет». Я видел, что передо мною перевод, так что это моё выражение — просто оговорка.
2) На самом деле «вдвое больше вспоминать» не только за счёт роста длины имени метода в два раза, но также и за счёт увеличения числа самих методов вдвое же. Может быть, вернее было бы мне сообщить, что «вчетверо больше вспоминать» приходится, но уверенности в этом у меня нет.
jquery — это фактически DSL. Грамотный, удобный, но DSL…
Поэтому cчитаю их методология не может являться примером для coding-style обычного js.
Поэтому cчитаю их методология не может являться примером для coding-style обычного js.
DSL в смысле «domain-specific language» или в смысле «definitive software library»?
Кстати тот самый подход, getCSS и setCSS используется в mootools.
Как насчет пробела перед списком аргументов в анонимных функциях?
Например,
но
Например,
function sum(a, b) {}
но
var sum = function (a, b) {};
Без пробела
var sum = function(a, b) {
};
В jQuery — по-разному.
Крокфорд рекомендует ставить.
А вот еще вопрос на засыпку: стоит ли объявлять переменные в начале функции? Что если переменная используется только в цикле?
Лично я не вижу ничего страшного в таком двойном объявлении:
Крокфорд рекомендует ставить.
А вот еще вопрос на засыпку: стоит ли объявлять переменные в начале функции? Что если переменная используется только в цикле?
Лично я не вижу ничего страшного в таком двойном объявлении:
function foo() {
...
for (var i=0; i<a.length; i++) {
console.log(a[i]);
}
for (var i=0; i<b.length; i++) {
console.log(b[i]);
}
}
Используйте как в примере: Google, npm, Node
var thisIsObject = new Date;
Про объекты вообще ничего не понял. А как еще можно это использовать?
И поправьте ошибку в заголовке этой части в слове Объекты…
Любой современный редактор позволяет забиндить на клавишу TAB сколь угодное кол-во пробелов.
Причины почему нужно использовать пробелы, а не табы можно найти даже в самих гайдлайнах/кодстайлах:
RSR-2:
PEAR:
Список гайдлайнов в поддержку пробелов: sprng.me/ife6p
RSR-2:
N.b.: Using only spaces, and not mixing spaces with tabs, helps to avoid problems with diffs, patches, history, and annotations. The use of spaces also makes it easy to insert fine-grained sub-indentation for inter-line alignment.
PEAR:
This helps to avoid problems with diffs, patches, SVN history and annotations.
Список гайдлайнов в поддержку пробелов: sprng.me/ife6p
Я, например, очень много кода просматриваю в браузере. И смотреть на подобное мне совершенно не хочется.
Он отформатирован исключительно табами и наверняка выглядит не так плохо в настроенном текстовом редакторе автора. К слову, почти весь код на гитхабе, отформатированный табами, в той или иной степени разъезжается.
Ну и не совсем понятно, почемы вы назвали это говнокодом. Потому что он плохо отображается в браузере? Не шедевр, конечно, но не так уж всё и плохо.
Ну и не совсем понятно, почемы вы назвали это говнокодом. Потому что он плохо отображается в браузере? Не шедевр, конечно, но не так уж всё и плохо.
Eclipse и Ctrl-Shift-F вообще чудеса творят
JSLint все решил за меня. Не со всем я, конечно, согласен ( в частности от пробелов в «function ($arg) {» меня каждый раз телепает), но любой единый стандарт в бесконечность раз лучше, чем любая «вкусовщина»
P.S: С чем не смог смириться в JSLint'е — запрет на ++ / — и подчеркивание в начале имен. Это уже перебор.
Вот поэтому-то позвольте ещё раз обратить Ваше внимание на важнейшее из обстоятельств в том переводе, который 505abc опубликовал: можно и нужно перейти с JSLint на JSHint, потому что у JSHint есть множество настроек, позволяющих настроить его именно на проверку какого надо стиля кодирования.
В частности, запрет на«++» и «--» по умолчанию отключён в JSHint. (Можно включить, но я бы не рекомендовал.)
В частности, запрет на
Понимаете, лично для меня это множество настроек — это огромнейший минус. Либо у языка какой-то стандарт кодирования есть (All hail pep8), либо его нет и стилем написания каждого отдельного файла каждый автор будет пытаться выразить свой огромный внутренний мир и чувство прекрасного.
Dura jslint sed jslint
P.S: в jslint эти две опции тоже отключаются, но я уже почти достигнирваны понимания того, что даже их отключать не нужно.
Dura jslint sed jslint
P.S: в jslint эти две опции тоже отключаются, но я уже почти достиг
Это статья как-раз таки о том, что надо выроботать общий стиль что-бы не слишком-то рушить огромные, но хрупкие миры каждого отдельного программиста в команде. Более того вам никто не мешает настроить JSHint под себя, и перестать героические преодолевать трудности создаваемые JSLint (если таковые имеются).
Лично я предпочитаю гибкие инструменты, которые можно настроить под себя. Это требует времени, но стоит того. Не хочу затрагивать тему open-source и проприетарного софта, но направление мысли, я думаю, вы поняли.
Лично я предпочитаю гибкие инструменты, которые можно настроить под себя. Это требует времени, но стоит того. Не хочу затрагивать тему open-source и проприетарного софта, но направление мысли, я думаю, вы поняли.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Оформление кода, оптимизация процесса проверки качества кода