Comments 61
UFO just landed and posted this here
UFO just landed and posted this here
Баг рипорт мэйнтейнерам оптимизатора. У ECMAscript абсолютно четкая грамматика.
Ловцу бага от этого будет не легче :)
Людям, которые пишут оптимизаторы, очень полезны подобные фидбэки. Они могут просто не знать о подобных проблемах.
Вносите свою лепту в инструменты, которыми пользуетесь.
Пример из моей жизни: Я в 98 году написал класс, который куда только не пастили. Года через 3 пришел баг репорт, о том, что класс не верно себя ведёт с аутлуком. Всех изменений — добавить \r. В сети на форумах нашел пару десятков веток, как обойти этот баг.
MiKXMan, Вы уверены, что вместо того, чтобы автор добавил строчку в BNF, нужно сидеть тихо и клепать воркараунды? Вы, уверены, что авторы продуктов, которыми Вы пользуетесь не заслуживают чести получить репорт, что бы улучшить своё детище? Вы уверены, в продукте, который не получает или не исправляет репортов?
Да, конечно написать толковый репорт — час времени. Или каждый должен ловить свои баги?
Вносите свою лепту в инструменты, которыми пользуетесь.
Пример из моей жизни: Я в 98 году написал класс, который куда только не пастили. Года через 3 пришел баг репорт, о том, что класс не верно себя ведёт с аутлуком. Всех изменений — добавить \r. В сети на форумах нашел пару десятков веток, как обойти этот баг.
MiKXMan, Вы уверены, что вместо того, чтобы автор добавил строчку в BNF, нужно сидеть тихо и клепать воркараунды? Вы, уверены, что авторы продуктов, которыми Вы пользуетесь не заслуживают чести получить репорт, что бы улучшить своё детище? Вы уверены, в продукте, который не получает или не исправляет репортов?
Да, конечно написать толковый репорт — час времени. Или каждый должен ловить свои баги?
UFO just landed and posted this here
Не может. Или это катастрофически сломанный минимизатор, не поддерживающий JS, зачем тогда его использовать.
Давайте еще по IE6 определять, какой JS хороший, а какой плохой.
Давайте еще по IE6 определять, какой JS хороший, а какой плохой.
Хороший перевод хорошей статьи. Но коль тема у нас оптимизация процесса проверки качества кода. То хочу добавить, что JSDOC аннотации + google closure compiler позволяют многие типы ошибок, начиная с синтаксиса и проверкой типов, и заканчивая необъявленные переменными или недоступным кодом.
Помимо jslint и jshint очень советую использовать github.com/mdevils/node-jscs.
Даешь холивар «таб vs пробелы»! И больная же тема.
Да разве только «таб vs пробелы»?!
Тут холиваров не на один месяц статей:
— Пробел между аргументами и выражением
— Кавычки
— Открывающая скобка
…
Тут холиваров не на один месяц статей:
— Пробел между аргументами и выражением
— Кавычки
— Открывающая скобка
…
UFO just landed and posted this here
Для меня двух пробелов мало, а четырёх — много.
Использую поэтому три пробела.
Использую поэтому три пробела.
Хорошо бы такие требования свести в таблицу (для аргументации в мелких рабочих группах, почему так лучше или так), а также дополнить все правила аргументациями, почему лучше так, а не иначе. И наконец, перечислить кодоформматоры — что они умеют и для каких языков (будет болльшая таблица — фичи по горизонтали, языки по вертикали, форматоры в ячейках).
* Например, когда лучше пробелы, а когда — табы, об этом много писали в статьях ранее.
* Почему лучше одиночные кавычки в 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;
Про объекты вообще ничего не понял. А как еще можно это использовать?
И поправьте ошибку в заголовке этой части в слове Объекты…
UFO just landed and posted this here
UFO just landed and posted this here
Любой современный редактор позволяет забиндить на клавишу TAB сколь угодное кол-во пробелов.
UFO just landed and posted this here
Причины почему нужно использовать пробелы, а не табы можно найти даже в самих гайдлайнах/кодстайлах:
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
UFO just landed and posted this here
Я, например, очень много кода просматриваю в браузере. И смотреть на подобное мне совершенно не хочется.
UFO just landed and posted this here
Он отформатирован исключительно табами и наверняка выглядит не так плохо в настроенном текстовом редакторе автора. К слову, почти весь код на гитхабе, отформатированный табами, в той или иной степени разъезжается.
Ну и не совсем понятно, почемы вы назвали это говнокодом. Потому что он плохо отображается в браузере? Не шедевр, конечно, но не так уж всё и плохо.
Ну и не совсем понятно, почемы вы назвали это говнокодом. Потому что он плохо отображается в браузере? Не шедевр, конечно, но не так уж всё и плохо.
UFO just landed and posted this here
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 и проприетарного софта, но направление мысли, я думаю, вы поняли.
UFO just landed and posted this here
Sign up to leave a comment.
Оформление кода, оптимизация процесса проверки качества кода