How to become an author
Search
Write a publication
Pull to refresh

Comments 92

По 6.
Зачем всегда строгое равенство для выражений, выдающих всегда один тип данных и сравнивающих с этим же типом? Например, if(s.indexOf('a') ==-1)…?
Total votes 7: ↑3 and ↓4-1
Все банально — единообразие. Ordnung macht frei и все такое.
Совсем недавно начал понимать, зачем на самом деле в гайдах всегда прописывается точное количество пробелов, кавычки и так далее… Все оказалось просто, это нужно для быстрого поиска по огромным проектам. Одно дело, когда ты знаешь, что нужно найти что-то вроде $('#, а другое — что надо еще учесть варианты $( '#, $("# и так далее.
Тут то же самое — вполне может быть ситуация, что надо найти, например, indexOf(name) === 5, например, и в этой ситуации расписывать еще и ={2,3} регекспом каждый раз печально. Недавно пришлось разгребать один проект — так там из-за нестыковок в нотации у разработчиков несколько раз реально 10-15 минут искал определенное обращение. К счастью, с ним пришлось работать совсем недолго.

К подобной практике приучивают и препроцессоры, тот же самый coffeeScript, например, в принципе не умеет делать ==. Если написать if a==b, он превратит это в if (a===b). Когда начинаешь пользоваться точным равенством ===, какое-то время использование сравнение через == становится, гхм, непривычным. Просто попробуйте для сравнения.
Total votes 7: ↑7 and ↓0+7
UFO just landed and posted this here
Обычно пишу так if (!!~s.indexOf('a')), с первого взгляда покажется бредом. Но после глаза привыкают к такому выражению.
Total votes 6: ↑1 and ↓5-4
А я-то думал, что самое извращенное что может быть это 
if (s.indexOf('a')+1)
Total votes 1: ↑0 and ↓1-1
Простого ~s.indexOf('a') было бы достаточно, потому что «!!» внутри «if» подразумевается.
Total votes 2: ↑2 and ↓0+2
Иногда хочется, чтобы на Хабре была страница со всеми цитируемыми картинками: двумя выше, с буханкой из тролейбуса, с еще десятком, которые постоянно, к месту и нет, упоминаются, хотя бы по одной-две, в подобных постах — и именно на эту страницу все комментаторы, считающие графику свежим, неизбитым ответом, ссылались бы. Чес-слово, ребят, ну уже даже не смешно.
Total votes 11: ↑9 and ↓2+7
тут скорее «14 стандартов? чуваки, а давайте посмотрим решения, которые использует большинство, и возьмем их, а заодно опишем почему так делать — хорошо».
Total votes 6: ↑2 and ↓4-2
Ну, как мне показалось, не совсем.
Было «от jQuery, Google, ideomatic.js и Crockford».
Из них взяли все, что посчитали самым удобным и появился еще один Style Guide от AirBnB.
Total votes 1: ↑1 and ↓0+1
Спасибо вашей команде за перевод, но я не заметил, чтобы там описывалось «почему», просто установка «Используйте табуляцию из двух пробелов». А почему? Почему не 4 или 8?
Total votes 4: ↑4 and ↓0+4
Просто потому что это популярное решение, вот и все. Большинство придерживается того же стиля, и им будет проще перейти: это плюс как для новых разработчиков, так и для опенсорс-сообщества, например.
Total votes 4: ↑3 and ↓1+2
Ну во-первых предъявите статистику, прежде чем утверждать, что этого способа придерживается большинство (я не про пробелы, а про все утверждения).
А во-вторых «так делает большинство» это не причина. Или вы сторонник мнения «миллиард китайцев не может ошибаться»?
Просто вы навязываете ничем не обоснованный подход. Либо объясняйте почему именно так, а не иначе, либо называйте это «принятые в нашей команде стандарты»
Total votes 7: ↑5 and ↓2+3
хорошо, я повторюсь.
Руководства по написанию JavaScript — Google, npm, Node.js, Idiomatic — придерживаются софтверных табов в 2 пробела.
Четыре пробела предлагается только крокфордской нотацией.

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

В IntelliJ по умолчанию используются софтверные отступы в 2 таба — а я думаю, вы не станете спорить, что это на данный момент наиболее популярная среда разработки.

Относительно «это не причина». Это причина: большинство людей пришло к именно двум табам, поскольку это удобно. Это субьективно удобно для большинства, и если предстоит работать с большинством — сделайте так, чтобы большинству было удобно. Если оно вам нужно, конечно.
Total votes 12: ↑6 and ↓60
В IntelliJ по умолчанию используются софтверные отступы в 2 таба — а я думаю, вы не станете спорить, что это на данный момент наиболее популярная среда разработки.
В IntelliJ по умолчанию 4 пробела.
Total votes 8: ↑7 and ↓1+6
большинство людей пришло к именно двум табам
100% проектов, на которых я был за 7 лет работы использовали исключительно 4 пробела (я не считаю сторонние библиотеки). Но я не буду утвержать, что «большинство» пришло к 4 табам. Чтобы вообще заикаться про «большинство» нужно предоставлять какую-то конкретную, достаточно большую выборку, а не полагаться на личный опыт.
Total votes 8: ↑8 and ↓0+8
я не про пробелы, а про все утверждения
Раз уж вы так активно ринулись доказывать, то пройдитесь по всему списку, а не одному пункту.

Лично я не против стандартов, я поддерживаю многое из того, что описано в руководстве. Но вы говорите о нём не как об очередном стандарте, а как о непреклонной истине, да ещё и смеете утверждать, что там сказано «почему так делать хорошо». Или я слеп и не увидел «почему», или вы врёте.

… и выше вам уже сказали «В IntelliJ по умолчанию 4 пробела» (хотя, подозреваю, это может зависеть от конкретного продукта и версии)
Total votes 3: ↑2 and ↓1+1
Какое-то странное голосование, для библиотек куча неизвестных названий и нет JQuery, для источников reusable code аналогично, нет stackoverflow.com, у меня оттуда 99%.
This comment wasn’t rated yet0
Наверно именно поэтому, что 99% их и нет. А то от этого голосования не было бы смысла: 99 vs 1.
This comment wasn’t rated yet0
Надеюсь они воспользуются вашей логикой на следующих выборах президента России.
Total votes 2: ↑1 and ↓10
Просто потому что это популярное решение

Интересно, почему у JS разработчиков это более популярное решение? В популярных языках (Java, C#, PHP, Python) везде 4 пробела, а здесь два.
Total votes 1: ↑1 and ↓0+1
потому что в js куда сильнее, чем в перечисленных языках, распространена передача колбэков в аргументы вызовов. а от вложеных колбэков indentation пухнет
Total votes 2: ↑1 and ↓10
2 пробела у Ruby и CoffeeScript.

Раньше, сложнее было понять, где отступ, потому 4 пробела было удобней, чем 2. Сейчас с дополнительной подсветкой (IDEA) надобность в 4 пробелах отпадает.
This comment wasn’t rated yet0
Комбинация из частей «стандартов» — новый «стандарт». Другое дело, если бы был выбран какой-то один существующий и просто объявлен наилучшим.
This comment wasn’t rated yet0
О, а я практически по ней для одного из проектов с нуля сделал fullstack фреймворк в три сотни строк :) Спасибо за тот перевод, он очень помог.
Total votes 1: ↑1 and ↓0+1
Используя «изоморфный туториал»?
This comment wasn’t rated yet0
Ну, вы скорее подкрепили мои намерения сделать его, но как минимум мне очень сильно помогло упоминание browserify, о котором я до этого не слышал, до этого использовал такой костыль (подсмотренный у одного товарища):

  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-модуль. Но это я потом расскажу, в одном из следующих постов.
Total votes 1: ↑1 and ↓0+1
Прикольно. Ждем поста.
This comment wasn’t rated yet0
// плохо
var items = getItems();
var goSportsTeam = true;
var dragonball = 'z';

// хорошо
var items = getItems(),
    goSportsTeam = true,
    dragonball = 'z';

Да почему же вот так? Что в этом хорошего?
Если все переменные объявить через var — я любую могу закомментировать/удалить без лишних телодвижений, а какие приемущества у такого синтаксиса?
Total votes 10: ↑7 and ↓3+4
Первое.
Не знаю как у вас, а у меня в intelliJ любая строка интеллектуально(с учетом окружения) комментируется по ctrl+/
Второе.
Появляется возможность сразу же визуально отделить блок, где находятся переменные, и блок, где находится основной код. Соответственно — видно, куда можно добавить еще одну переменную. А мы помним, что их надо добавлять в начало окружения, так как все же неправильно доверяться компилятору в переносе в рамках окружения — есть риск самому запутаться, если объявить переменную где-либо в конце. Соответственно добавлять переменные нужно именно в начале. Да и сразу можно увидеть список всех переменных окружения.
Третье.
Я не помню на моей памяти ни одного случая, когда мне реально нужно было комментировать переменную. Куски кода — да, но переменную — ни разу, максимум изменять значение или переименовывать: переменные при инициализации начинают хранить данные, а не совершать действия, и эти данные либо могут понадобиться (так что оставляем переменную), либо точно не понадобятся (удаляем). Сценарий комментирования переменной мне с трудом представляется, единственное, что приходит в голову — это нужно для заигрываний с глобальным скопом.
Total votes 10: ↑3 and ↓7-4
Первое, третье — ок, второе — не понимаю, как несколько var мешают читабельности. Ну отделите блок переменных пустой строкой и все.
Total votes 6: ↑6 and ↓0+6
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.
—
A better coding convention for lists and object literals in JavaScript
В общем, у каждого подхода есть свои особенности — нельзя говорить, что так плохо. Это стиль кодирования который нужно просто принять придя работать в компанию. AirBnB выложили свое видение.

var ни чуть ни хуже визуально отбивает блок и при добавлении или удалении новой переменной в коммит попадает +1 или -1 строка, а не -1 строка и +2 строки. В общем то на каждое ваше утверждение можно найти противовес. Ну и оправдания вида «не приходилось» — эт не спортивно ;)

PS я использую 2 подход т.к. вся моя команда приняла решение использовать его.
Total votes 5: ↑5 and ↓0+5
Не знаю как у вас, а у меня в intelliJ любая строка интеллектуально(с учетом окружения) комментируется по ctrl+/

Не знаю, как там комментирует IntelliJ, но скажем у вас три приведённых переменных, вам надо закомментировать вторую. А потом раскомментировать. Мы получим в итоге 3 исходных строки? Честно сказать, не верю, с комментированием всё более-менее понятно, а в момент раскомментирования будет неоднозначность, это неформализуемая процедура в общем случае.
И потом, получается стандарт привязывает к определённой IDE? В общем, более чем сомнительный момент.
This comment wasn’t rated yet0
В читаемости. Вы читаете код гораздо чаще, чем его комментируете/удаляете. И когда в коде встречается строка, и в ней var вынесен в начало блока, а далее с отступом идут строки объявления переменных, то сразу понятно, где начало блока, а где конец.
Когда переменные объявляются каждая на своей строчке, то глазу труднее выделить, где что находится.
Total votes 7: ↑4 and ↓3+1
В читаемости. Вы читаете код гораздо чаще, чем его комментируете/удаляете.
С этим никто и не спорит.

И когда в коде встречается строка, и в ней var вынесен в начало блока, а далее с отступом идут строки объявления переменных, то сразу понятно, где начало блока, а где конец.
Проблема в том, что это вам нужно видеть начало и конце «блока переменных». У других таких блоков, возможно, в принципе нет. В итоге получаем решение проблемы которую сами и создали :(
Total votes 1: ↑1 and ↓0+1
Ну некоторые вещи сомнительны, непонятно почему:
— 4 пробела плохо, 2 хорошо,
— "name" плохо, 'name' хорошо,
— self, that плохо, _this хорошо
Total votes 3: ↑2 and ↓1+1
Добавлю:
— «Оставляйте новую строку в конце файла.»
— dragon.age();, dragon.age(25);, в jquery такое повсеместно используется и пока никто не жаловался
This comment wasn’t rated yet0
— 4 пробела плохо, 2 хорошо
наиболее популярное решение, нужно для читаемости при передаче проектов просто: разработчики смущаются, видя разницу в отступах в два раза. Этим пользуются почти все, так что «придерживаемся большинства».

— «name» плохо, 'name' хорошо
Опять же «придерживаемся большинства». А единообразие в кавычках необходимо, т.к. очень важно для поиска. Я выше пример писал.

— self, that плохо, _this хорошо
this обычно подсвечивается в IDE как спецслово, что помогает его визуально отличать. префикс _ тоже помогает визуально отделять ее от обычных переменных. Self и that на первый взгляд кажутся тоже обычными переменными.
Total votes 9: ↑4 and ↓5-1
«name» плохо, 'name' хорошо
потомучто 
'<div class="item">'
self, that плохо, _this хорошо
_ визаульно искать гораздо проще, self не отличить от остального кода
Добавлю:
— «Оставляйте новую строку в конце файла.»
очевидно для того чтобы при склеивании, последняя строка файла n не спуталась с первой строкой файла n+1
Total votes 4: ↑3 and ↓1+2
'name' хорошо
1) При поиске строки 'name' нужно искать только один раз.
2) Одиночная кавычка легче на вид.
3) Во многих ЯП двойная кавычка используется для инлайн шаблонов — будет меньше путаницы если использовать одинарную.
Total votes 2: ↑1 and ↓10
Очевидно что при склеивании, склейщик должен сам об этом позаботиться.
Спасибо cyberface, частенько вызывая cat для разных файлов натыкался на отсутствие перевода строки перед $, добавлю в настройки редакторов
Total votes 3: ↑3 and ↓0+3
Опять же нельзя однозначно утверждать про self vs _this. self используется в ряде языков как ссылка на лексический контекст (и тем кто пишет на том языке и на JS проще понять такой код). Плюс подчеркивание у _this визуально зашумляет код. Да и есть еще 3 подход, когда запрещается замыкать псевдо-лексический контекст. Те всегда использовать .bind(this) или другим способом прокидывать контекст.
Total votes 5: ↑5 and ↓0+5
потомучто
'<div class="item">'
Значит я должен так писать?
alert('Error'+"\n"+'У вас ошибка!');


_ визаульно искать гораздо проще
… особенно среди прочих псевдо-приватных переменных
Total votes 2: ↑1 and ↓10
Значит я должен так писать?
alert('Error'+"\n"+'У вас ошибка!');

Насколько я помню одинарные и двойные кавычки в js равнозначны, это Вам не PHP =)
Т.е. вполне достаточно написать просто:
alert('Error\nУ вас ошибка!');
без конкатенаций…
Total votes 3: ↑3 and ↓0+3
Совершенно верно. Посыпаю голову пеплом )
Total votes 1: ↑1 and ↓0+1
потомучто
'<div class=«item»>'

Да, многие используют одинарные кавычки в JS именно по этой причине. В своё время тоже так делал.
Была такая система: в PHP (когда ещё писал на PHP) использовал двойные кавычки, в джаваскрипте одинарные, в HTML двойные. В итоге, можно было в PHP без проблем генерировать блоки на JS, а в JS на HTML (проблемы только в случае двойной вложенности — т.е. HTML внутри JS внутри PHP).
Но дело в том, что такой стиль — это уже немного прошлое десятилетие. Во времена повсеместного использования шаблонизаторов писать HTML-блок внутри строки — дурной тон. Поэтому уже года два использую только двойные кавычки везде, для унификации.
Кстати, если на то пошло, то никто не мешает использовать в HTML одинарные кавычки (это допускается стандартом и прекрасно понимается всеми браузерами), т.е. пример на самом деле легко переворачивается.
Total votes 1: ↑1 and ↓0+1
А в чем необходимость ставить; всегда? Это для минификации?
Total votes 1: ↑1 and ↓0+1
Не правда. github.com/twbs/bootstrap/blob/master/js/affix.js
Это опять же просто общепризнанный стиль.
Программист не должен заботиться о склейщиках, минификаторах и прочих инструментах — они сами должны заботиться о программисте. Они для того и созданы
Total votes 3: ↑2 and ↓1+1
По опыту скажу — в стороннем проекте видел, что js-файлы собирались не через grunt-contrib-uglify, а через grunt-contrib-concat, separator: ''.
Так что это скорее защита от дурака, как и добавление еще одной строки в конце.
Ну и да, общепризнанный стиль тоже — чтобы всегда можно было продолжить писать код в файле, не проверяя, есть ли там в конце точка с запятой.
This comment wasn’t rated yet0
UFO just landed and posted this here
В событие всегда передается в качестве объект, чтобы его можно было расширить в процессе всплытия;
Это, я не побоюсь этого слова, крайне не верный подход использования событий. Обработчики событий не должны знать о существовании друг друга и соответственно должны воспринимать переданные им данные как свои личные (в режиме read only). События вне DOM не гарантируют порядок выполнения обработчиков. И не стоит завязыватся на то, что кто первый подписался тот первый получит уведомление.

Вот вы представьте только: у вас 2 модуля оба подписаны на событие и один из них пропатчивает data — второй не ожидает такого поведения и все ломается. В DOM и в тех же jQuery.Event каждому обработчику передается уникальный event.
Total votes 3: ↑3 and ↓0+3
Для одновременных слушателей элемента это некорректно. Однако для всплытия — это вполне корректное поведение: клик всплывает к body однозначно позже того, как он сработал на a.
Это не лучшая практика, однако в некоторых условиях она допустима, и лучше предусмотреть этот сценарий, хотя использовать его в качестве основного не стоит.
This comment wasn’t rated yet0
jQuery-переменным задается префикс $;
Опять же, спорное правило. Если на проекте jQuery выбран в качестве основы для всего и вся — писать каждый раз этот $ становится глупо, так как все DOM-элементы всюду в коде уже заведомо обернуты в jQuery.
Total votes 1: ↑1 and ↓0+1
$ визуально отделяет DOM(jQuery) от JS-a.
Total votes 4: ↑2 and ↓20
Каким образом? И зачем?
Total votes 1: ↑1 and ↓0+1
Первый вопрос странный или я его не понял — отвечу наличием $ в начале имени переменной. Проще читать код и работать с ним, проще искать переменные, из имени переменной уже понятно как с ней работать, не нужно писать вербозных суффиксов: $name vs name vs nameElement. Вот Angular все испортил со своим $scope :)
Total votes 2: ↑1 and ↓10
Я говорю про случай, когда в проекте nameElement нет. Вообще. Только jQuery-вские объекты.

Да и зачем искать переменные? IDE же их и так выделяет.
This comment wasn’t rated yet0
Хорошо. jQuery это просто обертка над DOM те фактически DOM просто пофиксенный. Остается $name vs name в этом случае первоая переменная расскажет больше о своем содержании чем вторая (придется догадаться, почитать код).
Total votes 3: ↑2 and ↓1+1
Чем jQuery-объекты такие особенные? В 99% случаем уже по названию переменной либо по ближайшему окружению будет ясно, что там элемент, а не что-то еще. Или вы также предлагаете под каждый тип данных заваодить свой префикс?

Префикс $ очень полезен, когда в одном коде у вас смешаны raw dom objects и jQuery обертки. Когда действительно у имен button и $button будет разный смысл — $ устраняет неоднозначность.

Но если в коде неоднозначности нет — чем $button, $mainTable, $sidePanel будут лучше button, mainTable и sidePanel?
Total votes 2: ↑1 and ↓10
Разве обычных переменных в коде не бывает, только jQuery-обертки, да dom-ноды? :}
Total votes 1: ↑1 and ↓0+1
Можете привести пример реального кода, где по названию переменной будет не ясно, лежит ли в ней кнопка или, скажем, число?
Total votes 1: ↑0 and ↓1-1
UFO just landed and posted this here
Потому что надо называть переменную peopleCountDisplay или peopleCountBtn. Псевдо-венгерская псевдо-нотация утомила уже.
Total votes 3: ↑1 and ↓2-1
В вашем примере вы используете $ как замену более длинному суффиксу «Element» (или его вариациям).

Сравните:
var peopleCountElement = $('#people_count'), peopleCount = peopleCountElement.val();

Читаемость пострадала? Нет.

Хочу обратить внимание, что в данной ситуации это не тот «Element», который используется для выделения raw DOM elements в коде с лишь частичным использованием jQuery.

Вместо «Element» могут быть вариации на тему «Holder», «Div», «Span» и т.д. Зависит от контекста.

Пока не убедили.
Total votes 1: ↑0 and ↓1-1
Когда я читаю peopleCountElement я сразу вижу DOM элемент; $peopleCount — jQuery; Element Div и Ко будут сбивать с толку если в проекте есть jQuery.
Total votes 2: ↑2 and ↓0+2
Еще раз — речь о проекте, где только jQuery. В подавляющем большнистве случаев у вас нет конфликта между названиями переменных как в примере выше.
Total votes 1: ↑0 and ↓1-1
UFO just landed and posted this here
И что мешает конкретно в этом случае вам взять и, если ничего другого не приходит в голову, конкретно в этом случае воспользоваться префиксом $? Или ради этого обязательно захламлять весь остальной код префиксами?
This comment wasn’t rated yet0
UFO just landed and posted this here
Ну не знаю. Для меня это спор о вкусах фломастеров. За последние несколько лет дай бог чтобы 4-5 раз возникала ситуация, где было бы реально нужно работать с DOM напрямую и префикс магически бы решал все проблемы :)

По примеру выше, буквально недавно нужно было порисовать стрелочки с канвасом. Код выглядел примерно вот так:
function getContext() {
    return $('#canvas').get(0).getContext('2d');
}

Собственно всё. Никакой драмы.

This comment wasn’t rated yet0
UFO just landed and posted this here
А кто говорит, что он больше одного раза вызывается? ) Что мешает закэшировать результат? )

Код дробят на отдельные функции не только чтобы выделить дублирующуюся логику, но и чтобы просто выделить логически изолированные блоки.
This comment wasn’t rated yet0
Прям всем и каждому хочется возразить, к каждому пункту можно придраться. Но знаете что скажу? Главное — чтобы все придерживались единого стандарта, выбранного потом, кровью и криками.
Total votes 7: ↑7 and ↓0+7
Я хочу сказать Вам большое спасибо, за проделанную работу.
Total votes 4: ↑2 and ↓20
Изложенная в руководстве AirBnB идея использовать массивы и метод join для конкатенации строк представляется мне слабоприемлемою (затрудняя постижение смысла кода), вне зависимости от её влияния на производительности джаваскрипта в IE.
Total votes 4: ↑2 and ↓20
По поводу перевода
// TODO: должна быть возможность изменять значение через параметр функции
this.total = 0;

Мне кажется не верным переводить или писать комментарии на русском языке, даже в проектах, где все его знают.
Total votes 2: ↑1 and ↓10
Почему, я вот наоборот считаю? Русскоязычная команда — комментарии должны быть русские. Зачем костыли? Другое дело, если ты делаешь свой «мега-фреймворк», который должен тебе принести межгалактическую известность…
Total votes 2: ↑0 and ↓2-2
А завтра в вашу русскоязычную команду войдёт сотрудник из Пакистана.
Total votes 2: ↑2 and ↓0+2
Еще один. В большинстве конечно согласен, тем более что ничего нового они не придумали, но в топку такие туториалы, которые несовместимы с большинством IDE и добавляют нераберихи в давние войны тупоконечников и остроконечников. Это я про табы в два пробела.
Total votes 4: ↑4 and ↓0+4
Sign up to leave a comment.

Your account

Sections

Information

Services

Support
© 2006–2024, Habr