Comments 61
Большое спасибо. Google style в очередной раз оказался милее других. Ох уж эта Империя 'Добра'.
UFO landed and left these words here
Баг рипорт мэйнтейнерам оптимизатора. У ECMAscript абсолютно четкая грамматика.
Людям, которые пишут оптимизаторы, очень полезны подобные фидбэки. Они могут просто не знать о подобных проблемах.
Вносите свою лепту в инструменты, которыми пользуетесь.

Пример из моей жизни: Я в 98 году написал класс, который куда только не пастили. Года через 3 пришел баг репорт, о том, что класс не верно себя ведёт с аутлуком. Всех изменений — добавить \r. В сети на форумах нашел пару десятков веток, как обойти этот баг.

MiKXMan, Вы уверены, что вместо того, чтобы автор добавил строчку в BNF, нужно сидеть тихо и клепать воркараунды? Вы, уверены, что авторы продуктов, которыми Вы пользуетесь не заслуживают чести получить репорт, что бы улучшить своё детище? Вы уверены, в продукте, который не получает или не исправляет репортов?
Да, конечно написать толковый репорт — час времени. Или каждый должен ловить свои баги?
UFO landed and left these words here
Конечно, ведь иных вариантов нет.
Или работающий до минимизации корректный код не будет работать.
UFO landed and left these words here
UFO landed and left these words here
Не может. Или это катастрофически сломанный минимизатор, не поддерживающий JS, зачем тогда его использовать.
Давайте еще по IE6 определять, какой JS хороший, а какой плохой.
Хороший перевод хорошей статьи. Но коль тема у нас оптимизация процесса проверки качества кода. То хочу добавить, что JSDOC аннотации + google closure compiler позволяют многие типы ошибок, начиная с синтаксиса и проверкой типов, и заканчивая необъявленные переменными или недоступным кодом.
Да разве только «таб vs пробелы»?!
Тут холиваров не на один месяц статей:
— Пробел между аргументами и выражением
— Кавычки
— Открывающая скобка
Я, конечно, в холиваре «tab vs пробелы» не участвую, давно для себя всё решил оптимальным образом.
Но почему 2 пробела, а не 4 – искренне не понимаю.
Потому, что в 2 раза меньше места занимает по горизонтали при большой вложенности.
Ну и что? Сейчас экраны пошли за горизонтальное место переживать особо не стоит. Тем более, учитывая рекомендацию ограничения в 80 символов.
Зато визуально намного легче воспринимается.
Если вложенность большая (например 3 цикла for), то меньше пробелов рисовать. Если что я за табы.
Если что – я тоже. Но все IDE умеют при должной настройке по клавише Tab нарисовать нужное количество пробелов.
Ну, видимо, экономят место по-ширине (как уже написано выше). Мне, если что, тоже 4 пробела удобней чем 2: воспринимается легче.
Но почему 2 пробела, а не 4

Чтобы куча вложенных callback-ов не вылезала за границы широкоформатного монитора 80 символов?
Для меня двух пробелов мало, а четырёх — много.

Использую поэтому три пробела.
Все правильно, надо делать как удобно, а не как «принято».

(Сам раньше использовал отступ в 7 символов.)
Хорошо бы такие требования свести в таблицу (для аргументации в мелких рабочих группах, почему так лучше или так), а также дополнить все правила аргументациями, почему лучше так, а не иначе. И наконец, перечислить кодоформматоры — что они умеют и для каких языков (будет болльшая таблица — фичи по горизонтали, языки по вертикали, форматоры в ячейках).

* Например, когда лучше пробелы, а когда — табы, об этом много писали в статьях ранее.
* Почему лучше одиночные кавычки в JS, а двойные — в HTML — потому что так меньше конфликтов при записи одного в другом, а двойные в HTML традиционны.
* Почему лучше запятые перед объявлением — потому что сразу и на одном месте видно, что означает очередная строка, не глядя в её конец.
* Всегда точка с запятой — потому что бывают ошибки при сцеплении строк с переносом, когда конец одной — без точки с запятой, а начало следующей — скобка.
Вы пишете об использовании слов «is», «set», «get» в именах функций, что библиотека jQuery «без особого мнения».

На самом же деле библиотека jQuery построена таким образом, что употребление этих слов в именах функций исключается. Один и тот же метод объекта может совершать и get (например, «$('div.hh').css('color')»), и set (например, «$('div.hh').css('color', '#7FA0B0')»).

И это правильное построение. Если бы вместо этого существовали два разные метода getCSS() и setCSS(), то программисту пришлось бы вдвое больше вспоминать и вдвое больше набирать каждый раз (имя метода стало бы вдвое длиннее).
Два важных уточнения:

1) На самом деле не «Вы пишете», а «Otto Kekäläinen пишет». Я видел, что передо мною перевод, так что это моё выражение — просто оговорка.

2) На самом деле «вдвое больше вспоминать» не только за счёт роста длины имени метода в два раза, но также и за счёт увеличения числа самих методов вдвое же. Может быть, вернее было бы мне сообщить, что «вчетверо больше вспоминать» приходится, но уверенности в этом у меня нет.
jquery — это фактически DSL. Грамотный, удобный, но DSL…
Поэтому cчитаю их методология не может являться примером для coding-style обычного js.
Как насчет пробела перед списком аргументов в анонимных функциях?

Например,
function sum(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 landed and left these words here
Согласен. Тем более, благодаря возможностям IDE, разработчик может настроить размер табуляции по своему вкусу.
Любой современный редактор позволяет забиндить на клавишу TAB сколь угодное кол-во пробелов.
UFO landed and left these words here
Причины почему нужно использовать пробелы, а не табы можно найти даже в самих гайдлайнах/кодстайлах:

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 landed and left these words here
UFO landed and left these words here
Он отформатирован исключительно табами и наверняка выглядит не так плохо в настроенном текстовом редакторе автора. К слову, почти весь код на гитхабе, отформатированный табами, в той или иной степени разъезжается.
Ну и не совсем понятно, почемы вы назвали это говнокодом. Потому что он плохо отображается в браузере? Не шедевр, конечно, но не так уж всё и плохо.
UFO landed and left these words here
Ну т.е. вы приняли решение основываясь на форматировании.
Упустил момент, когда мы перешли на «ты».
Причин, почему нужно использовать таб вместо пробелов – тоже достаточно.
Основная причина – отсутствие стандарта на размер отступа.
Если вы используете пробелы – вы фактически навязываете разработчиу, который потом будет смотреть ваш код, свои привычные отступы.
В случае же использования табов его <название любимой IDE> выровняет код по его настройкам.
Ясное дело, что это касается только отступов в начале строки. Для выравнивания внутри кода надо пользоваться только пробелами.
JSLint все решил за меня. Не со всем я, конечно, согласен ( в частности от пробелов в «function ($arg) {» меня каждый раз телепает), но любой единый стандарт в бесконечность раз лучше, чем любая «вкусовщина»
P.S: С чем не смог смириться в JSLint'е — запрет на ++ / — и подчеркивание в начале имен. Это уже перебор.
Вот поэтому-то позвольте ещё раз обратить Ваше внимание на важнейшее из обстоятельств в том переводе, который 505abc опубликовал: можно и нужно перейти с JSLint на JSHint, потому что у JSHint есть множество настроек, позволяющих настроить его именно на проверку какого надо стиля кодирования.

В частности, запрет на «++» и «--» по умолчанию отключён в JSHint. (Можно включить, но я бы не рекомендовал.)
Понимаете, лично для меня это множество настроек — это огромнейший минус. Либо у языка какой-то стандарт кодирования есть (All hail pep8), либо его нет и стилем написания каждого отдельного файла каждый автор будет пытаться выразить свой огромный внутренний мир и чувство прекрасного.

Dura jslint sed jslint

P.S: в jslint эти две опции тоже отключаются, но я уже почти достиг нирваны понимания того, что даже их отключать не нужно.
Это статья как-раз таки о том, что надо выроботать общий стиль что-бы не слишком-то рушить огромные, но хрупкие миры каждого отдельного программиста в команде. Более того вам никто не мешает настроить JSHint под себя, и перестать героические преодолевать трудности создаваемые JSLint (если таковые имеются).

Лично я предпочитаю гибкие инструменты, которые можно настроить под себя. Это требует времени, но стоит того. Не хочу затрагивать тему open-source и проприетарного софта, но направление мысли, я думаю, вы поняли.
UFO landed and left these words here
Only those users with full accounts are able to leave comments. Log in, please.