Comments 92
По 6.
Зачем всегда строгое равенство для выражений, выдающих всегда один тип данных и сравнивающих с этим же типом? Например, if(s.indexOf('a') ==-1)…?
Зачем всегда строгое равенство для выражений, выдающих всегда один тип данных и сравнивающих с этим же типом? Например, if(s.indexOf('a') ==-1)…?
Все банально — единообразие. Ordnung macht frei и все такое.
Совсем недавно начал понимать, зачем на самом деле в гайдах всегда прописывается точное количество пробелов, кавычки и так далее… Все оказалось просто, это нужно для быстрого поиска по огромным проектам. Одно дело, когда ты знаешь, что нужно найти что-то вроде $('#, а другое — что надо еще учесть варианты $( '#, $("# и так далее.
Тут то же самое — вполне может быть ситуация, что надо найти, например, indexOf(name) === 5, например, и в этой ситуации расписывать еще и ={2,3} регекспом каждый раз печально. Недавно пришлось разгребать один проект — так там из-за нестыковок в нотации у разработчиков несколько раз реально 10-15 минут искал определенное обращение. К счастью, с ним пришлось работать совсем недолго.
К подобной практике приучивают и препроцессоры, тот же самый coffeeScript, например, в принципе не умеет делать ==. Если написать if a==b, он превратит это в if (a===b). Когда начинаешь пользоваться точным равенством ===, какое-то время использование сравнение через == становится, гхм, непривычным. Просто попробуйте для сравнения.
Совсем недавно начал понимать, зачем на самом деле в гайдах всегда прописывается точное количество пробелов, кавычки и так далее… Все оказалось просто, это нужно для быстрого поиска по огромным проектам. Одно дело, когда ты знаешь, что нужно найти что-то вроде $('#, а другое — что надо еще учесть варианты $( '#, $("# и так далее.
Тут то же самое — вполне может быть ситуация, что надо найти, например, indexOf(name) === 5, например, и в этой ситуации расписывать еще и ={2,3} регекспом каждый раз печально. Недавно пришлось разгребать один проект — так там из-за нестыковок в нотации у разработчиков несколько раз реально 10-15 минут искал определенное обращение. К счастью, с ним пришлось работать совсем недолго.
К подобной практике приучивают и препроцессоры, тот же самый coffeeScript, например, в принципе не умеет делать ==. Если написать if a==b, он превратит это в if (a===b). Когда начинаешь пользоваться точным равенством ===, какое-то время использование сравнение через == становится, гхм, непривычным. Просто попробуйте для сравнения.
Обычно пишу так if (!!~s.indexOf('a')), с первого взгляда покажется бредом. Но после глаза привыкают к такому выражению.
Иногда хочется, чтобы на Хабре была страница со всеми цитируемыми картинками: двумя выше, с буханкой из тролейбуса, с еще десятком, которые постоянно, к месту и нет, упоминаются, хотя бы по одной-две, в подобных постах — и именно на эту страницу все комментаторы, считающие графику свежим, неизбитым ответом, ссылались бы. Чес-слово, ребят, ну уже даже не смешно.
тут скорее «14 стандартов? чуваки, а давайте посмотрим решения, которые использует большинство, и возьмем их, а заодно опишем почему так делать — хорошо».
Ну, как мне показалось, не совсем.
Было «от jQuery, Google, ideomatic.js и Crockford».
Из них взяли все, что посчитали самым удобным и появился еще один Style Guide от AirBnB.
Было «от jQuery, Google, ideomatic.js и Crockford».
Из них взяли все, что посчитали самым удобным и появился еще один Style Guide от AirBnB.
на самом деле есть еще nodeguide.com/style.html, npmjs.org/doc/coding-style.html и github.com/Seravo/js-winning-style. Но это уже мелочи.
Спасибо вашей команде за перевод, но я не заметил, чтобы там описывалось «почему», просто установка «Используйте табуляцию из двух пробелов». А почему? Почему не 4 или 8?
Просто потому что это популярное решение, вот и все. Большинство придерживается того же стиля, и им будет проще перейти: это плюс как для новых разработчиков, так и для опенсорс-сообщества, например.
Ну во-первых предъявите статистику, прежде чем утверждать, что этого способа придерживается большинство (я не про пробелы, а про все утверждения).
А во-вторых «так делает большинство» это не причина. Или вы сторонник мнения «миллиард китайцев не может ошибаться»?
Просто вы навязываете ничем не обоснованный подход. Либо объясняйте почему именно так, а не иначе, либо называйте это «принятые в нашей команде стандарты»
А во-вторых «так делает большинство» это не причина. Или вы сторонник мнения «миллиард китайцев не может ошибаться»?
Просто вы навязываете ничем не обоснованный подход. Либо объясняйте почему именно так, а не иначе, либо называйте это «принятые в нашей команде стандарты»
хорошо, я повторюсь.
Руководства по написанию JavaScript — Google, npm, Node.js, Idiomatic — придерживаются софтверных табов в 2 пробела.
Четыре пробела предлагается только крокфордской нотацией.
Первые четыре руководства используются большинством веб-студий, которые в принципе используют какие-либо гайды. Когда мы выбирали подходящую стилистику — я опросил не один десяток веб-студий и агентств, и если там и использовались стили, то использовались Google или Idiomatic, была всего одна команда, которая сослалась на Крокфорд как основу.
В IntelliJ по умолчанию используются софтверные отступы в 2 таба — а я думаю, вы не станете спорить, что это на данный момент наиболее популярная среда разработки.
Относительно «это не причина». Это причина: большинство людей пришло к именно двум табам, поскольку это удобно. Это субьективно удобно для большинства, и если предстоит работать с большинством — сделайте так, чтобы большинству было удобно. Если оно вам нужно, конечно.
Руководства по написанию JavaScript — Google, npm, Node.js, Idiomatic — придерживаются софтверных табов в 2 пробела.
Четыре пробела предлагается только крокфордской нотацией.
Первые четыре руководства используются большинством веб-студий, которые в принципе используют какие-либо гайды. Когда мы выбирали подходящую стилистику — я опросил не один десяток веб-студий и агентств, и если там и использовались стили, то использовались Google или Idiomatic, была всего одна команда, которая сослалась на Крокфорд как основу.
В IntelliJ по умолчанию используются софтверные отступы в 2 таба — а я думаю, вы не станете спорить, что это на данный момент наиболее популярная среда разработки.
Относительно «это не причина». Это причина: большинство людей пришло к именно двум табам, поскольку это удобно. Это субьективно удобно для большинства, и если предстоит работать с большинством — сделайте так, чтобы большинству было удобно. Если оно вам нужно, конечно.
В IntelliJ по умолчанию используются софтверные отступы в 2 таба — а я думаю, вы не станете спорить, что это на данный момент наиболее популярная среда разработки.В IntelliJ по умолчанию 4 пробела.
.editorconfig + EditorConfig и конец этому занудному холивару про табы и пробелы. Сколько уж можно!
большинство людей пришло к именно двум табам100% проектов, на которых я был за 7 лет работы использовали исключительно 4 пробела (я не считаю сторонние библиотеки). Но я не буду утвержать, что «большинство» пришло к 4 табам. Чтобы вообще заикаться про «большинство» нужно предоставлять какую-то конкретную, достаточно большую выборку, а не полагаться на личный опыт.
я не про пробелы, а про все утвержденияРаз уж вы так активно ринулись доказывать, то пройдитесь по всему списку, а не одному пункту.
Лично я не против стандартов, я поддерживаю многое из того, что описано в руководстве. Но вы говорите о нём не как об очередном стандарте, а как о непреклонной истине, да ещё и смеете утверждать, что там сказано «почему так делать хорошо». Или я слеп и не увидел «почему», или вы врёте.
… и выше вам уже сказали «В IntelliJ по умолчанию 4 пробела» (хотя, подозреваю, это может зависеть от конкретного продукта и версии)
Есть статистика DailyJS за 2012 без учета количества пробелов
Indentation with spaces 1421 53%
Indentation with tabs 1038 39%
dailyjs.com/files/2012-survey-summary.pdf
Сейчас идет голосование 2013 года dailyjs.com/2013/11/28/javascript-survey/ там набор вопросов больше.
Indentation with spaces 1421 53%
Indentation with tabs 1038 39%
dailyjs.com/files/2012-survey-summary.pdf
Сейчас идет голосование 2013 года dailyjs.com/2013/11/28/javascript-survey/ там набор вопросов больше.
Просто потому что это популярное решение
Интересно, почему у JS разработчиков это более популярное решение? В популярных языках (Java, C#, PHP, Python) везде 4 пробела, а здесь два.
потому что в js куда сильнее, чем в перечисленных языках, распространена передача колбэков в аргументы вызовов. а от вложеных колбэков indentation пухнет
2 пробела у Ruby и CoffeeScript.
Раньше, сложнее было понять, где отступ, потому 4 пробела было удобней, чем 2. Сейчас с дополнительной подсветкой (IDEA) надобность в 4 пробелах отпадает.
Раньше, сложнее было понять, где отступ, потому 4 пробела было удобней, чем 2. Сейчас с дополнительной подсветкой (IDEA) надобность в 4 пробелах отпадает.
Комбинация из частей «стандартов» — новый «стандарт». Другое дело, если бы был выбран какой-то один существующий и просто объявлен наилучшим.
Отличные ребята, недавно делал перевод их статьи: Изоморфный JavaScript — будущее веб-приложений
О, а я практически по ней для одного из проектов с нуля сделал fullstack фреймворк в три сотни строк :) Спасибо за тот перевод, он очень помог.
Используя «изоморфный туториал»?
Ну, вы скорее подкрепили мои намерения сделать его, но как минимум мне очень сильно помогло упоминание browserify, о котором я до этого не слышал, до этого использовал такой костыль (подсмотренный у одного товарища):
Если интересно — для рутинга на клиенте использую очень похожий на роутер express page.js, шаблоны — jade с рендерингом в js-модуль. Но это я потом расскажу, в одном из следующих постов.
if (typeof module !== 'undefined') {
module.exports = App;
} else if (typeof exports !== 'undefined') {
exports.App = App;
} else if (!('WeakMap' in global)) {
global.App = App;
}
Если интересно — для рутинга на клиенте использую очень похожий на роутер express page.js, шаблоны — jade с рендерингом в js-модуль. Но это я потом расскажу, в одном из следующих постов.
Посмотрите еще в сторону LMD.
Прикольно. Ждем поста.
// плохо
var items = getItems();
var goSportsTeam = true;
var dragonball = 'z';
// хорошо
var items = getItems(),
goSportsTeam = true,
dragonball = 'z';
Да почему же вот так? Что в этом хорошего?
Если все переменные объявить через var — я любую могу закомментировать/удалить без лишних телодвижений, а какие приемущества у такого синтаксиса?
Первое.
Не знаю как у вас, а у меня в intelliJ любая строка интеллектуально(с учетом окружения) комментируется по ctrl+/
Второе.
Появляется возможность сразу же визуально отделить блок, где находятся переменные, и блок, где находится основной код. Соответственно — видно, куда можно добавить еще одну переменную. А мы помним, что их надо добавлять в начало окружения, так как все же неправильно доверяться компилятору в переносе в рамках окружения — есть риск самому запутаться, если объявить переменную где-либо в конце. Соответственно добавлять переменные нужно именно в начале. Да и сразу можно увидеть список всех переменных окружения.
Третье.
Я не помню на моей памяти ни одного случая, когда мне реально нужно было комментировать переменную. Куски кода — да, но переменную — ни разу, максимум изменять значение или переименовывать: переменные при инициализации начинают хранить данные, а не совершать действия, и эти данные либо могут понадобиться (так что оставляем переменную), либо точно не понадобятся (удаляем). Сценарий комментирования переменной мне с трудом представляется, единственное, что приходит в голову — это нужно для заигрываний с глобальным скопом.
Не знаю как у вас, а у меня в intelliJ любая строка интеллектуально(с учетом окружения) комментируется по ctrl+/
Второе.
Появляется возможность сразу же визуально отделить блок, где находятся переменные, и блок, где находится основной код. Соответственно — видно, куда можно добавить еще одну переменную. А мы помним, что их надо добавлять в начало окружения, так как все же неправильно доверяться компилятору в переносе в рамках окружения — есть риск самому запутаться, если объявить переменную где-либо в конце. Соответственно добавлять переменные нужно именно в начале. Да и сразу можно увидеть список всех переменных окружения.
Третье.
Я не помню на моей памяти ни одного случая, когда мне реально нужно было комментировать переменную. Куски кода — да, но переменную — ни разу, максимум изменять значение или переименовывать: переменные при инициализации начинают хранить данные, а не совершать действия, и эти данные либо могут понадобиться (так что оставляем переменную), либо точно не понадобятся (удаляем). Сценарий комментирования переменной мне с трудом представляется, единственное, что приходит в голову — это нужно для заигрываний с глобальным скопом.
Первое, третье — ок, второе — не понимаю, как несколько var мешают читабельности. Ну отделите блок переменных пустой строкой и все.
ALL code is ugly. Yours, mine, everyone’s. Code Is Ugly. Just face it. When someone says “beautiful code”, hear “beautiful rotten entrails”. The only beautiful code, the most clean code, is no code at all. If it’s there, it’s ugly. The unfortunate fact of software development is that, in order to create beautiful software, we must use ugly code.В общем, у каждого подхода есть свои особенности — нельзя говорить, что так плохо. Это стиль кодирования который нужно просто принять придя работать в компанию. AirBnB выложили свое видение.
—
A better coding convention for lists and object literals in JavaScript
var ни чуть ни хуже визуально отбивает блок и при добавлении или удалении новой переменной в коммит попадает +1 или -1 строка, а не -1 строка и +2 строки. В общем то на каждое ваше утверждение можно найти противовес. Ну и оправдания вида «не приходилось» — эт не спортивно ;)
PS я использую 2 подход т.к. вся моя команда приняла решение использовать его.
Не знаю как у вас, а у меня в intelliJ любая строка интеллектуально(с учетом окружения) комментируется по ctrl+/
Не знаю, как там комментирует IntelliJ, но скажем у вас три приведённых переменных, вам надо закомментировать вторую. А потом раскомментировать. Мы получим в итоге 3 исходных строки? Честно сказать, не верю, с комментированием всё более-менее понятно, а в момент раскомментирования будет неоднозначность, это неформализуемая процедура в общем случае.
И потом, получается стандарт привязывает к определённой IDE? В общем, более чем сомнительный момент.
В читаемости. Вы читаете код гораздо чаще, чем его комментируете/удаляете. И когда в коде встречается строка, и в ней var вынесен в начало блока, а далее с отступом идут строки объявления переменных, то сразу понятно, где начало блока, а где конец.
Когда переменные объявляются каждая на своей строчке, то глазу труднее выделить, где что находится.
Когда переменные объявляются каждая на своей строчке, то глазу труднее выделить, где что находится.
В читаемости. Вы читаете код гораздо чаще, чем его комментируете/удаляете.С этим никто и не спорит.
И когда в коде встречается строка, и в ней var вынесен в начало блока, а далее с отступом идут строки объявления переменных, то сразу понятно, где начало блока, а где конец.Проблема в том, что это вам нужно видеть начало и конце «блока переменных». У других таких блоков, возможно, в принципе нет. В итоге получаем решение проблемы которую сами и создали :(
Ну некоторые вещи сомнительны, непонятно почему:
— 4 пробела плохо, 2 хорошо,
—
— self, that плохо, _this хорошо
— 4 пробела плохо, 2 хорошо,
—
"name" плохо, 'name' хорошо,— self, that плохо, _this хорошо
Добавлю:
— «Оставляйте новую строку в конце файла.»
—
— «Оставляйте новую строку в конце файла.»
—
dragon.age();, dragon.age(25);, в jquery такое повсеместно используется и пока никто не жаловался
— 4 пробела плохо, 2 хорошо
наиболее популярное решение, нужно для читаемости при передаче проектов просто: разработчики смущаются, видя разницу в отступах в два раза. Этим пользуются почти все, так что «придерживаемся большинства».
— «name» плохо, 'name' хорошо
Опять же «придерживаемся большинства». А единообразие в кавычках необходимо, т.к. очень важно для поиска. Я выше пример писал.
— self, that плохо, _this хорошо
this обычно подсвечивается в IDE как спецслово, что помогает его визуально отличать. префикс _ тоже помогает визуально отделять ее от обычных переменных. Self и that на первый взгляд кажутся тоже обычными переменными.
наиболее популярное решение, нужно для читаемости при передаче проектов просто: разработчики смущаются, видя разницу в отступах в два раза. Этим пользуются почти все, так что «придерживаемся большинства».
— «name» плохо, 'name' хорошо
Опять же «придерживаемся большинства». А единообразие в кавычках необходимо, т.к. очень важно для поиска. Я выше пример писал.
— self, that плохо, _this хорошо
this обычно подсвечивается в IDE как спецслово, что помогает его визуально отличать. префикс _ тоже помогает визуально отделять ее от обычных переменных. Self и that на первый взгляд кажутся тоже обычными переменными.
«name» плохо, 'name' хорошопотомучто
'<div class="item">'self, that плохо, _this хорошо_ визаульно искать гораздо проще, self не отличить от остального кода
Добавлю:очевидно для того чтобы при склеивании, последняя строка файла n не спуталась с первой строкой файла n+1
— «Оставляйте новую строку в конце файла.»
'name' хорошо1) При поиске строки
'name' нужно искать только один раз. 2) Одиночная кавычка легче на вид.
3) Во многих ЯП двойная кавычка используется для инлайн шаблонов — будет меньше путаницы если использовать одинарную.
Очевидно что при склеивании, склейщик должен сам об этом позаботиться.
Спасибо cyberface, частенько вызывая
Спасибо cyberface, частенько вызывая
cat для разных файлов натыкался на отсутствие перевода строки перед $, добавлю в настройки редакторовОпять же нельзя однозначно утверждать про
self vs _this. self используется в ряде языков как ссылка на лексический контекст (и тем кто пишет на том языке и на JS проще понять такой код). Плюс подчеркивание у _this визуально зашумляет код. Да и есть еще 3 подход, когда запрещается замыкать псевдо-лексический контекст. Те всегда использовать .bind(this) или другим способом прокидывать контекст.потомучтоЗначит я должен так писать?
'<div class="item">'
alert('Error'+"\n"+'У вас ошибка!');
_ визаульно искать гораздо проще… особенно среди прочих псевдо-приватных переменных
потомучто
'<div class=«item»>'
Да, многие используют одинарные кавычки в JS именно по этой причине. В своё время тоже так делал.
Была такая система: в PHP (когда ещё писал на PHP) использовал двойные кавычки, в джаваскрипте одинарные, в HTML двойные. В итоге, можно было в PHP без проблем генерировать блоки на JS, а в JS на HTML (проблемы только в случае двойной вложенности — т.е. HTML внутри JS внутри PHP).
Но дело в том, что такой стиль — это уже немного прошлое десятилетие. Во времена повсеместного использования шаблонизаторов писать HTML-блок внутри строки — дурной тон. Поэтому уже года два использую только двойные кавычки везде, для унификации.
Кстати, если на то пошло, то никто не мешает использовать в HTML одинарные кавычки (это допускается стандартом и прекрасно понимается всеми браузерами), т.е. пример на самом деле легко переворачивается.
спасибо за перевод, и особенно за краткий пересказ)
А в чем необходимость ставить; всегда? Это для минификации?
именно
Не правда. github.com/twbs/bootstrap/blob/master/js/affix.js
Это опять же просто общепризнанный стиль.
Программист не должен заботиться о склейщиках, минификаторах и прочих инструментах — они сами должны заботиться о программисте. Они для того и созданы
Это опять же просто общепризнанный стиль.
Программист не должен заботиться о склейщиках, минификаторах и прочих инструментах — они сами должны заботиться о программисте. Они для того и созданы
По опыту скажу — в стороннем проекте видел, что js-файлы собирались не через grunt-contrib-uglify, а через grunt-contrib-concat, separator: ''.
Так что это скорее защита от дурака, как и добавление еще одной строки в конце.
Ну и да, общепризнанный стиль тоже — чтобы всегда можно было продолжить писать код в файле, не проверяя, есть ли там в конце точка с запятой.
Так что это скорее защита от дурака, как и добавление еще одной строки в конце.
Ну и да, общепризнанный стиль тоже — чтобы всегда можно было продолжить писать код в файле, не проверяя, есть ли там в конце точка с запятой.
Это одно из мест где можно избежать ошибки при аuto semicolon insertion.
В событие всегда передается в качестве объект, чтобы его можно было расширить в процессе всплытия;Это, я не побоюсь этого слова, крайне не верный подход использования событий. Обработчики событий не должны знать о существовании друг друга и соответственно должны воспринимать переданные им данные как свои личные (в режиме read only). События вне DOM не гарантируют порядок выполнения обработчиков. И не стоит завязыватся на то, что кто первый подписался тот первый получит уведомление.
Вот вы представьте только: у вас 2 модуля оба подписаны на событие и один из них пропатчивает data — второй не ожидает такого поведения и все ломается. В DOM и в тех же jQuery.Event каждому обработчику передается уникальный event.
Для одновременных слушателей элемента это некорректно. Однако для всплытия — это вполне корректное поведение: клик всплывает к body однозначно позже того, как он сработал на a.
Это не лучшая практика, однако в некоторых условиях она допустима, и лучше предусмотреть этот сценарий, хотя использовать его в качестве основного не стоит.
Это не лучшая практика, однако в некоторых условиях она допустима, и лучше предусмотреть этот сценарий, хотя использовать его в качестве основного не стоит.
jQuery-переменным задается префикс $;Опять же, спорное правило. Если на проекте jQuery выбран в качестве основы для всего и вся — писать каждый раз этот $ становится глупо, так как все DOM-элементы всюду в коде уже заведомо обернуты в jQuery.
$ визуально отделяет DOM(jQuery) от JS-a.
Каким образом? И зачем?
Первый вопрос странный или я его не понял — отвечу наличием $ в начале имени переменной. Проще читать код и работать с ним, проще искать переменные, из имени переменной уже понятно как с ней работать, не нужно писать вербозных суффиксов: $name vs name vs nameElement. Вот Angular все испортил со своим $scope :)
Я говорю про случай, когда в проекте nameElement нет. Вообще. Только jQuery-вские объекты.
Да и зачем искать переменные? IDE же их и так выделяет.
Да и зачем искать переменные? IDE же их и так выделяет.
Хорошо. jQuery это просто обертка над DOM те фактически DOM просто пофиксенный. Остается $name vs name в этом случае первоая переменная расскажет больше о своем содержании чем вторая (придется догадаться, почитать код).
Чем jQuery-объекты такие особенные? В 99% случаем уже по названию переменной либо по ближайшему окружению будет ясно, что там элемент, а не что-то еще. Или вы также предлагаете под каждый тип данных заваодить свой префикс?
Префикс $ очень полезен, когда в одном коде у вас смешаны raw dom objects и jQuery обертки. Когда действительно у имен button и $button будет разный смысл — $ устраняет неоднозначность.
Но если в коде неоднозначности нет — чем $button, $mainTable, $sidePanel будут лучше button, mainTable и sidePanel?
Префикс $ очень полезен, когда в одном коде у вас смешаны raw dom objects и jQuery обертки. Когда действительно у имен button и $button будет разный смысл — $ устраняет неоднозначность.
Но если в коде неоднозначности нет — чем $button, $mainTable, $sidePanel будут лучше button, mainTable и sidePanel?
Разве обычных переменных в коде не бывает, только jQuery-обертки, да dom-ноды? :}
Можете привести пример реального кода, где по названию переменной будет не ясно, лежит ли в ней кнопка или, скажем, число?
Потому что надо называть переменную peopleCountDisplay или peopleCountBtn. Псевдо-венгерская псевдо-нотация утомила уже.
Я просто оставлю это здесь: www.joelonsoftware.com/articles/Wrong.html
В вашем примере вы используете $ как замену более длинному суффиксу «Element» (или его вариациям).
Сравните:
Читаемость пострадала? Нет.
Хочу обратить внимание, что в данной ситуации это не тот «Element», который используется для выделения raw DOM elements в коде с лишь частичным использованием jQuery.
Вместо «Element» могут быть вариации на тему «Holder», «Div», «Span» и т.д. Зависит от контекста.
Пока не убедили.
Сравните:
var peopleCountElement = $('#people_count'), peopleCount = peopleCountElement.val();Читаемость пострадала? Нет.
Хочу обратить внимание, что в данной ситуации это не тот «Element», который используется для выделения raw DOM elements в коде с лишь частичным использованием jQuery.
Вместо «Element» могут быть вариации на тему «Holder», «Div», «Span» и т.д. Зависит от контекста.
Пока не убедили.
Когда я читаю
peopleCountElement я сразу вижу DOM элемент; $peopleCount — jQuery; Element Div и Ко будут сбивать с толку если в проекте есть jQuery.Еще раз — речь о проекте, где только jQuery. В подавляющем большнистве случаев у вас нет конфликта между названиями переменных как в примере выше.
И что мешает конкретно в этом случае вам взять и, если ничего другого не приходит в голову, конкретно в этом случае воспользоваться префиксом $? Или ради этого обязательно захламлять весь остальной код префиксами?
Ну не знаю. Для меня это спор о вкусах фломастеров. За последние несколько лет дай бог чтобы 4-5 раз возникала ситуация, где было бы реально нужно работать с DOM напрямую и префикс магически бы решал все проблемы :)
По примеру выше, буквально недавно нужно было порисовать стрелочки с канвасом. Код выглядел примерно вот так:
Собственно всё. Никакой драмы.
По примеру выше, буквально недавно нужно было порисовать стрелочки с канвасом. Код выглядел примерно вот так:
function getContext() {
return $('#canvas').get(0).getContext('2d');
}
Собственно всё. Никакой драмы.
Благодаря вам узнал о github.com/trending, спасибо!
Прям всем и каждому хочется возразить, к каждому пункту можно придраться. Но знаете что скажу? Главное — чтобы все придерживались единого стандарта, выбранного потом, кровью и криками.
может кому-то будет интересна собственная компиляция многих популярных руководств
github.com/DarkPark/jscs
github.com/DarkPark/jscs
Я хочу сказать Вам большое спасибо, за проделанную работу.
Изложенная в руководстве AirBnB идея использовать массивы и метод join для конкатенации строк представляется мне слабоприемлемою (затрудняя постижение смысла кода), вне зависимости от её влияния на производительности джаваскрипта в IE.
По поводу перевода
Мне кажется не верным переводить или писать комментарии на русском языке, даже в проектах, где все его знают.
// TODO: должна быть возможность изменять значение через параметр функции
this.total = 0;
Мне кажется не верным переводить или писать комментарии на русском языке, даже в проектах, где все его знают.
Еще один. В большинстве конечно согласен, тем более что ничего нового они не придумали, но в топку такие туториалы, которые несовместимы с большинством IDE и добавляют нераберихи в давние войны тупоконечников и остроконечников. Это я про табы в два пробела.
Sign up to leave a comment.
Перевод AirBnB Style Guide