Comments 118
Все просто: JSLint про ошибки, JSCS про код-стайл.
Не могли бы вы привести больше примеров? Пока смутно понимаю, в чём принципиальное отличие. И в JSLint, и в вашем проекте можно настроить, например, необходимость фигурных скобок у
if .. else
, однако это не «ошибка», как вы пишете, а именно стиль оформления кода.JSLint не покрывает требований по кодстайлу наших проектов. Да и не развивается он. Если бы и развивался, то архитектура в JSLint настолько ужасно, что контрибьютить — это последнее, что хочется.
Ну так может вы приведете список стилевых правил, которые поддерживает сабж? :)
А то получается как в анекдоте:
— Я сделал изобретение, позволяющее видеть сквозь стены!
— Но оно уже давно существует.
— Как же оно называется?
— Окно.
А то получается как в анекдоте:
— Я сделал изобретение, позволяющее видеть сквозь стены!
— Но оно уже давно существует.
— Как же оно называется?
— Окно.
Их более 60-ти и все они описаны по ссылке, которую я привел в конце статьи: github.com/mdevils/node-jscs
1) JSLint — не только про ошибки.
2) Вы привели только один пример недостатка кода, который обнаруживает сабж: отсутствие пробела между
2) Вы привели только один пример недостатка кода, который обнаруживает сабж: отсутствие пробела между
function
и скобкой. JSLint это отлавливает.Цель моего вопроса была как раз в том, чтобы понять, какие уникальные настройки вы предоставляете в JSCS.
Предположим, есть проект, который использует JSLint. Как мне сконфигурировать(и для каких кейсов, что самое важное) JSCS, чтобы они не конфликтовали(ведь насколько я понял, у них есть дублирующий функционал)?
Предположим, есть проект, который использует JSLint. Как мне сконфигурировать(и для каких кейсов, что самое важное) JSCS, чтобы они не конфликтовали(ведь насколько я понял, у них есть дублирующий функционал)?
1) А с помощью утюга можно приготовить яичницу, например. Но вот испечь пирог будет проблемно.
2) Вы правы, пример с пробелом не очень-то наглядный, но идея понятна и всегда же можно перейти по урлу и мелько пробежаться глазами. Не поленитесь. Настроек очень много.
2) Вы правы, пример с пробелом не очень-то наглядный, но идея понятна и всегда же можно перейти по урлу и мелько пробежаться глазами. Не поленитесь. Настроек очень много.
Более того, поддержка JSLint имеется практически у всех IDE и редакторов кода. Недостатки кода подсвечиваются во время написания, а не при запуске консольной команды.
Чуть выше ответ.
Дело времени.
Будем ждать для PHPStorm / WebStorm. Или уже есть?
Пока нет, но есть задача, за которую можно проголосовать: youtrack.jetbrains.com/issue/WEB-10591
Время выполнения !!x — 12мс, Boolean(x) — 310. С одной стороны это — на миллионе операций, а с другой — разница больше чем на порядок. Отличный код стайл.
Скрытый текст
(function(){
var t = +new Date(), x = true;
for( var i = 1000000;--i;){
x = Boolean(x);
}
console.log(-(t-(t=new Date())));
for( var i = 1000000;--i;){
x = !!x;
}
console.log(-(t-(t=new Date())));
})();
Не знаю как вы, но я пишу код для людей, мучаться должны роботы и переделать код как им нужно при минификации ;)
Мне как и вам прочитать не сложно. Любой не посвященный в JS скажет, что
!!x
— читается как магия; Boolean(x)
— все понятно ;)Для непосвящённого в JS прототипное наследование — магия, например, что ж теперь, его выкидывать? Для тех, кто программирует на Си# странно, что замыкание создаётся только на уровне функций (а for, например, новую область не создаёт), так давайте не будем пользоваться замыкамиями! Они, кстати, сами по себе для многих — магия!
Поэтому не стоит делать из языка элитарное сообщество, ограниченное трехметровым порогом входа. Не забывайте, что есть ряд людей, которые не пишут фуллтайм на JS, но им приходится с ним работать.
Не совсем понял, что вы имели в виду под «замыкание создаётся только на уровне функций (а for, например, новую область не создаёт)» — можно пример кода для ясности?
Классика:
for (var i = 0; i < 3; i++) {
setTimeout(function () {
alert(i);
}, 100);
}
Я так и думал, но проверил следующим куском кода и он отработал ожидаемым образом, выведя последовательно числа от 0 до 4:
Не могу понять, в чем разница между вашим кодом и моим?
var data = [];
for(var idx = 0; idx < 5; idx++) {
var curr = function() { alert(idx); };
data.push(curr);
}
for(var idx = 0; idx < 5; idx++) {
data[idx]();
}
Не могу понять, в чем разница между вашим кодом и моим?
у вас во втором цикле переменная тоже называется idx, показывается ее значение
Здесь есть тонкий момент, во втором цикле вы на самом деле используете ту же самую переменную idx, что и в первом случае, попробуйте переименовать её в напрмер в jdx и все станет на свои места:
var data = [];
for(var idx = 0; idx < 5; idx++) {
var curr = function() { alert(idx); };
data.push(curr);
}
for(var jdx = 0; jdx < 5; jdx++) {
data[jdx]();
}
Ваш код синхронный. Мой асинхронный.
Это чуть ли не худший ответ, который вы могли дать. Он не просто неправильный — он может создать у новичка ложное ощущение правильного понимания причины проблемы.
Я ответил вполне на конкретный вопрос: «Не могу понять, в чем разница между вашим кодом и моим?». Не знаю стало ли проще если я бы ответил, что в JS область видимости через var создает только функция, поэтому в следующем тике event loop значение переменной будет 3 и эта переменная будет общая для всех безымянных «замыканий» аргумента setTimeout.
Прототипное наследование — одна из основных особенностей языка, а использование двойного отрицания для неявного приведения к булеву это использование фич языка не по назначению, побочное свойство некоторых особенностей.
Ну, любая поддержка кода требует понимания языка, на котором он написан. Я думаю, как bolk сказал ниже, проблема в том, что качество программистов падает, и людям становится слишком лениво разбираться в тонкостях работы с языком. Порой даже попадаются индивидумы, которые могут писать селекторы с использованием jQuery, но вытащить элемент по id на нативном JS не могут. Грустно всё это…
Вот уж не знаю, по моему все довольно очевидно, такой код вполне нормально работает в си/с++
Когда я первый раз встретился с ~~x, то тоже сначала растерялся, а ведь удобно.
Да это просто качество программистов падает. В языке разобраться лениво, поэтому писать можно только «не смущающими новичка конструкциями».
Почему-то сразу вспомнилось: www.99-bottles-of-beer.net/language-perl-737.html
В данном случае я не соглашусь с собой. Не вникал в поведение Boolean без new. Был уверен что это фабрики и что поведение может в итоге ожидаться такое, которое не смогут оптимизировать роботы. Но в яндексе при сборке кода Boolean без new скорее всего и превратится в !!.. То есть скорость исполнения будет та же. У скорости ввода есть две стороны. Обычно скорость написания кода упирается не в скорость печати. Новичкам и тем кто не знаком с js понятнее запись Boolean. С другой стороны я был уверен что абсолютно все кто касается js в яндексе среди ночи смогут рассказать всё про автоматическое приведение типов.
Да и статья о другом, думаю эту тулзу можно настроить в обратную сторону, что бы она ругалась когда вместо!!! стоит Boolean :).
Интереснее причина такого кодстайла где в js после function нужен пробел. Очень похоже на портированный PEP8.
Да и статья о другом, думаю эту тулзу можно настроить в обратную сторону, что бы она ругалась когда вместо!!! стоит Boolean :).
Интереснее причина такого кодстайла где в js после function нужен пробел. Очень похоже на портированный PEP8.
Сложнее прочитать. Не вникая в тонкости неявного приведения типов запись кажется семантически бессмысленной (двойное отрицание аргумента равносильно аргументу в булевой логике, а! булевый оператор), поведение в граничных случаях не очевидно. В общем, обычный хак. Если скорость выполнения важна, то согласно правилам хорошего тона его нужно дополнять комментарием типа
// fast convert to boolean
, а если не важна, то просто его не использовать.Попробуйте для подобных сравнений jsperf использовать — очень удобно.
jsperf.com/double-negative-vs-boolean
Кстати, мне тоже больше нравится!!! х, по сравнению с Boolean(x). Читается легче.
jsperf.com/double-negative-vs-boolean
Кстати, мне тоже больше нравится!!! х, по сравнению с Boolean(x). Читается легче.
Ну верно, ваш код стайл просто восхитителен.
Всякие
Boolean(x) === false
— читаемее, хоть запись и получается длиннее.Всякие
!!x
, и уж точно побитовые операции на вроде вашей +new Date()
или всякие ~array.indexOf(x)
стоит использовать только в больших циклах, где такая экономия на спичках имеет хоть какой-то смысл.Это звучит как «да ну ваше наследование через цепочку прототипов, я подключу CoffeeScript и буду писать классы».
Если честно, я не понял при чем здесь прототипы и классы. Разговор вообще о другом.
Речь о том, что логическое отрицание(!) или побитовое отрицание(~) — это просто и понятно. Это есть почти во всех языках программирования. Не знать этого довольно-таки странно для программиста. Исходя из вашего поста выше, вы пишете так:
вместо
верно?
if (Boolean(arr.length) === false) {
...
}
вместо
if (!arr.length) {
...
}
верно?
Вы кажется перегибаете, любой вменяемый программист будет писать
!arr.length
Я обычно пишу:
if (arr.length === 0) {
...
}
Да, мне, кстати, с недавних пор тоже стало нравиться писать так. Вообще, как по мне, практика с явным определением типов — штука правильная и хорошо дисциплинирует. Но другое дело, когда мы хотим проверить параметр объекта, возможно оно
false
, 0
или вовсе undefined
, вот тут я все же использую if (obj.param) {}
Для меня
0
и undefined
— это совершенно разные вещи и в одном условии я оба сразу не проверяю. Нет кейсов.Конечно разные. В данном случае я рассматривал 0 как упрощенный вариант
false
в качестве ответа от сервера. Но так же сервер и вовсе может не установить в качестве ответа ничего. А когда мы знаем, что, возможное значение — число, пусть даже 0, то это совсем другой разговор. Так что все это частные случаи.undefined вот таким словом лучше не писать никогда. undefined — не константа, его можно от скуки переопределить. === void 0 или typeof, но при typeof производится не бесплатная операция сравнения со строкой (хотя может тут работает оптимизация глобального места где хранятся все строки). Иногда ещё 'param' in obj пригождается.
Или в функциях, которые могут позвать из циклов. Или цикл может оказаться вложенным. Ещё забавно наблюдать как функцию мэппинга объявляют в цикле. Но я полностью согласен с тем что ресурсотерпящие вещи лучше писать читаемыми.
Мне кажется вы лукавите. Не знаю как там у вас, но я всегда знаю, какая функция чем может быть запущена, и окажется ли она в цикле. А если мы говорим про какие-то действительно монструозные вещи, на вроде библиотек, когда и правда не ясно, что будет делать другой разработчик с вашим кодом — то тогда уж точно разницы нет — время выполнения полезного кода будет выше, чем любая экономия.
Я говорю про функциональный подход. Когда в функции мэппинга делают ещё мэппинг. Тут уже на 1000 иттерациях может оказаться заметна разница. Библиотеки я как раз по этой причине избегаю почти все и использую microjs если есть конкретная задача, которая точно уже решена другими. Как наглядный пример такого подхода я обычно привожу конструкцию вида $('#el1').height(). Есть случаи когда достаточно сделать document.getElementById('el1').clientHeight. И вот в этом случае я прошу пройти по стеку того что делает жквери, что бы в итоге вызвать эту конструкцию. Но это важно в основном при отрисовке больших списков данных или когда мы пишем веб-приложение и весомая часть модели живёт в браузере. В случае если нам надо повесить событие на клик кнопки logout — тут действительно можно сделать это чем угодно. Но при этом событие mousemove использовать обёрнутое любой библиотекой — всё равно крайне не желательно, если мы хотим сделать плавную анимацию. Что-то я разошелся, оптимизация у меня — больная тема. :)
Boolean(x) === false
Зачем? Неужели так читаемее?
Я вам больше скажу, в таких местах даже читаемее использовать Йода-стайл на вроде
Только не нужно кидаться тухлыми помидорами, не попробовав на практике такой подход. Это мы тут с вами снипеты в 2 строки разбираем, на реальном же коде особенности оформления уже играют большую роль в понимании.
false === Boolean(x)
Только не нужно кидаться тухлыми помидорами, не попробовав на практике такой подход. Это мы тут с вами снипеты в 2 строки разбираем, на реальном же коде особенности оформления уже играют большую роль в понимании.
«Йода-стайл», как вы его назвали, родился вовсе не из читаемости. Соглашение «константа слева» спасает от ситуации, когда программист пропускает одно равно и получает if (a = false) вместо if (a == false). В вашем же случае «false === Boolean(x)» это соглашение лишнее, да и вообще вся конструкция должна умереть.
Не сочтите за грубость, но вы же мне просто глаза открыли. Тем более, что про указанное вами соглашение можно не беспокоиться в рамках JS, так как
if (x = 2) {}
вызывает ошибку. Я же не заставляю никого писать так, как нравится мне, и как пишет команда автора из Яндекса, а у них-то наверное больше аргументов на счет явного приведения типов.Дело скорее всего не в производительности, а в однозначности поведения. Чтобы код отрабатывал максимально одинаково на всех существующих известных, неизвестных и теоретически возможных платформах…
От этого спасут только тесты. Я вот был уверен что Boolean возвращает не примитив, а объект как в случае с new Boolean(false). И у меня есть уже немного опыта js, и потому я проверил и теперь знаю, а те кто делают код ревью могут не знать такой тонкости.
Проверить объект это или примитив можно присвоив свойства объекта, а потом взяв его.
Проверить объект это или примитив можно присвоив свойства объекта, а потом взяв его.
Микробенчмаркинг зло. Он показывает не цифры скорости какие-то цифры. JIT браузера очень интересно оптимизирует код.
Пропустите код выше через V8 со специальными флагами посмотрите на ASM код который получится. Будете удивлены)
Пропустите код выше через V8 со специальными флагами посмотрите на ASM код который получится. Будете удивлены)
А нет в планах пойти дальше и не просто выводить ошибки, а делать авто форматирование кода? Пиши как хочешь, а хук на pre-commit приводит весь код к единому код стайлу.
P.S. Сам пробовал jsbeautifier и esformatter, увы оба обладают своими недостатками, последний так совсем коверкает исходный файл.
P.S. Сам пробовал jsbeautifier и esformatter, увы оба обладают своими недостатками, последний так совсем коверкает исходный файл.
В планах этого нет. Цель проекта в том, чтобы помочь привыкнуть и с помощью CI — контролировать.
Есть проект, который может форматировать код, количество настроек там правда пока невелико.
github.com/jedmao/codepainter
github.com/jedmao/codepainter
Открывая статью надеялся, что это не про другой JSLint, а про автоматическое форматирование кода — настроил свои правила, и при чекауте получаешь JS-код в своём любимом стиле, а при коммите он переформатируется в принятый в команде.
Зачем мне сообщение о забытом пробеле и облом коммита? Компьютер железный — пусть он и расставляет (не)нужные пробелы.
Зачем мне сообщение о забытом пробеле и облом коммита? Компьютер железный — пусть он и расставляет (не)нужные пробелы.
1. Выбрать одно лучшее IDE (мы, например, выбрали IDEA)
2. Использовать дефолтные настройки и не лезть со своим Code Style (мы просто жмем Ctrl + Alt + L, срабатывает авто-форматирование и стиль у всех один)
2. Использовать дефолтные настройки и не лезть со своим Code Style (мы просто жмем Ctrl + Alt + L, срабатывает авто-форматирование и стиль у всех один)
UFO just landed and posted this here
А для виндузятников экзешник?
Вот смотрю я на эту форму фидбека и не могу придумать, какая там может быть нетривиальная логика внутри. Поделитесь, что она делает хоть, кроме очевидной отправки фидбека?
Рейтинг там примеру со звёздами, который можно попариться при наведении мышки красиво анимировать. Форма может увеличивается при наборе текста. Анимация при добавлении какая-нибудь.
Всегда легко посмотреть на что-нибудь вроде твиттера и хмыкнуть «ха, бложик на 140 знаков».
Всегда легко посмотреть на что-нибудь вроде твиттера и хмыкнуть «ха, бложик на 140 знаков».
А не было варианта просто настроить инспекции в каком-нибудь ВебШторме? Или том же Виме/Емаксе, я ими сам не пользуюсь, но раз они осиливают подсветку, значит с синтаксическими конструкциями работать в принципе можно.
Если честно, размер проекта на гитхабе поистине пугает. я бы ограничился примитивным скриптом, выдающим ошибки в типичном формате компиляторов <path>:<line>:<message>. Vim (syntactic), Emacs (compile/recompile, flymake) и ST (из коробки) прекрасно понимаю такой формат и позволяют прыгать к исходникам и выделать строки с ошибками.
Очень хорошо, что осведомили. Кабы карма Ваша не была и без того заплюсована мною — беспременно заплюсовал бы её сегодня.
А не то, видите ли, я до сих пор сидел на JSHint 2.x, потому что произошедшие в 3.x перемены (отказ от проверки стиля) ну никак не мог принять.
Конечно, теперь (когда есть отдельный стилепроверщик) — это неплохо. Есть куда убежать с JSHintовской проверки стиля.
(Хорошо бы кто-нибудь#138 пофиксил, конечно; но и без того очень, очень неплохо.)
А не то, видите ли, я до сих пор сидел на JSHint 2.x, потому что произошедшие в 3.x перемены (отказ от проверки стиля) ну никак не мог принять.
Конечно, теперь (когда есть отдельный стилепроверщик) — это неплохо. Есть куда убежать с JSHintовской проверки стиля.
(Хорошо бы кто-нибудь
UFO just landed and posted this here
Кода довольно много, что бы пролистать, поэтому проще спросить — проводится ли семантический анализ, посроение AST? Если нет, почему недостаточно регулярных выражений, на которые способно большинство полноценных текстовых редакторов, ну или sed awk? Какого рода парсинг проводится, если не секрет?
Парсинг и построение AST с помощью esprima.
Вызывает уважение. Тогда по обмену опытом, мой сейчас любимый язык Go включает такого рода утилиту форматирования в коробочной поставке. Конфигурация не предусматривается, поскольку полагается что весь код на Go должен быть написан единообразно. Зато присутствует зачаточная возможность символьной трансформации, то есть например можно задать правило 2*x -> x+x
Классика жанра:
Почему бы не сделать описание правил форматирования на основе BNF?
Что-то я не понял.
Есть команда, в которой принят некий стиль. Там же есть, видимо, специально обученный человек, который высматривает пробелы и грепает восклицательные знаки. Сам расставлять пробелы он не умеет, просто рефьюзит коммит. Вы (автор статьи) написали утилиту, которая заменяет этого человека. И команде ничего не говорили… Мне это как-то дико. Или в команде тоже используется какой-то инструмент, но вы решили написать свой? Или в команде у каждого свои костыли имеются? Я работал в разных командах и что-то не могу представить вашу ситуацию.
Спрашиваю потому, что уже не первый раз рассказы о том, как работает Яндекс, вводят меня в недоумение.
Есть команда, в которой принят некий стиль. Там же есть, видимо, специально обученный человек, который высматривает пробелы и грепает восклицательные знаки. Сам расставлять пробелы он не умеет, просто рефьюзит коммит. Вы (автор статьи) написали утилиту, которая заменяет этого человека. И команде ничего не говорили… Мне это как-то дико. Или в команде тоже используется какой-то инструмент, но вы решили написать свой? Или в команде у каждого свои костыли имеются? Я работал в разных командах и что-то не могу представить вашу ситуацию.
Спрашиваю потому, что уже не первый раз рассказы о том, как работает Яндекс, вводят меня в недоумение.
В каких-то странных командах вы работали.
Процедуру код ревью себе представляете? Я, на всякий случай расскажу. Вы пишете код, ваши коллеги его смотрят, пишут замечания, вы исправляете (ну или обосновываете, что написали как надо) код в соответствии с замечаниями, отправляете на повторное ревью и т.д…
То есть не нужен специальный человек для этого.
А автору статьи было сложно привыкнуть к новому для него стилю кода, и для помощи себе он написал утилиту, которая оказалась полезной множеству людей.
То что общепринятые практики разработки ПО вводят вас в недоумение, то у меня для вас плохие новости.
Процедуру код ревью себе представляете? Я, на всякий случай расскажу. Вы пишете код, ваши коллеги его смотрят, пишут замечания, вы исправляете (ну или обосновываете, что написали как надо) код в соответствии с замечаниями, отправляете на повторное ревью и т.д…
То есть не нужен специальный человек для этого.
А автору статьи было сложно привыкнуть к новому для него стилю кода, и для помощи себе он написал утилиту, которая оказалась полезной множеству людей.
То что общепринятые практики разработки ПО вводят вас в недоумение, то у меня для вас плохие новости.
Во-первых.
Мне всегда попадались люди, которые обнаруживали ошибки типа «это не заработает на python 2.3», «здесь лучше использовать другую структуру данных», «у нас принято писать комментарии на английском языке»… К пробелам и деталям типа «типов в языках со слабой типизацией» либо не привязывались, либо проверяли линтерами и прочими инструментами.
Во-вторых.
Мне попадались команды, где разработанные инструменты тут же становились общим достоянием. Макросы к редакторам, анализаторы логов, и даже форматировалки исходников. Все эти вещи разрабатывались совместно. И мне действительно трудно представить противоположную ситуацию. Почему человек вынужден делать для себя очевидный инструмент? Почему, сделав его, он не предлагает его команде? Ждёт, когда каждый сделает себе свой? Я действительно не понимаю логику такого поведения.
Мне всегда попадались люди, которые обнаруживали ошибки типа «это не заработает на python 2.3», «здесь лучше использовать другую структуру данных», «у нас принято писать комментарии на английском языке»… К пробелам и деталям типа «типов в языках со слабой типизацией» либо не привязывались, либо проверяли линтерами и прочими инструментами.
Во-вторых.
Мне попадались команды, где разработанные инструменты тут же становились общим достоянием. Макросы к редакторам, анализаторы логов, и даже форматировалки исходников. Все эти вещи разрабатывались совместно. И мне действительно трудно представить противоположную ситуацию. Почему человек вынужден делать для себя очевидный инструмент? Почему, сделав его, он не предлагает его команде? Ждёт, когда каждый сделает себе свой? Я действительно не понимаю логику такого поведения.
К пробелам и деталям типа «типов в языках со слабой типизацией» либо не привязывались, .
Ну, что не привязывались — в этом ничего хорошего нет, я сторонник строго придерживаться стайл-гайда.
либо проверяли линтерами и прочими инструментами
Вы ведь понимаете, что инструмент написали потому что подходящего не было?
Мне попадались команды, где разработанные инструменты тут же становились общим достоянием.
Статью читали? В статье явно написано, что с коллегами поделился. А теперь и со всеми желающими за пределами компании (что гораздо важнее, как мне кажется).
Вы выглядите приятным, разумным человеком, но в первом комментарии какую-то ерунду написали, честное слово.
Недавно наткнулся на ESLint. Проект позиционирует себя как модульная альтернатива jslint/jshint, где каждый может легко добавлять свои правила. К сожалению пока руки не дошли попробовать, но было бы интересно сравнить и узнать мнение тех кто пользовался
Уже много месяцев пользуюсь вашей разработкой в виде grunt-плагина grunt-jscs-checker во всех проектах. Ужасно доволен, спасибо вам огромное!
Не прочитал все коментарии, возможно уже спрашивали. Планируется ли сделать удобный интерфейс для генерации конфига jscs? Чтобы не читать весь ридми с последующей копипастой, а прощелкивать слайды, а в конце копировать конфиг?
Не прочитал все коментарии, возможно уже спрашивали. Планируется ли сделать удобный интерфейс для генерации конфига jscs? Чтобы не читать весь ридми с последующей копипастой, а прощелкивать слайды, а в конце копировать конфиг?
Мимо.
youtrack.jetbrains.com/issue/WEB-10591
Поддержите предложение для JetBrains по внедрению этого плагина в их IDE.
Поддержите предложение для JetBrains по внедрению этого плагина в их IDE.
Судя по камментам мало кто читал гитхаб и мало кто понял зачем данная итилита. Печально.
У нас в компании царят формат-фашизм и граммар-нацизм, поэтому JSCS наряду с JSHint стоит на хуках в репозиториях.
Нестильный код не пройдёт!
Спасибо за такую потрясающую утилиту.
Нестильный код не пройдёт!
Спасибо за такую потрясающую утилиту.
Sign up to leave a comment.
JSCS: JavaScript Code Style