Как стать автором
Поиск
Написать публикацию
Обновить

Комментарии 118

Все просто: JSLint про ошибки, JSCS про код-стайл.
Всего голосов 22: ↑17 и ↓5+12
Не могли бы вы привести больше примеров? Пока смутно понимаю, в чём принципиальное отличие. И в JSLint, и в вашем проекте можно настроить, например, необходимость фигурных скобок у if .. else, однако это не «ошибка», как вы пишете, а именно стиль оформления кода.
Всего голосов 5: ↑4 и ↓1+3
JSLint не покрывает требований по кодстайлу наших проектов. Да и не развивается он. Если бы и развивался, то архитектура в JSLint настолько ужасно, что контрибьютить — это последнее, что хочется.
Всего голосов 2: ↑1 и ↓10
Ну так может вы приведете список стилевых правил, которые поддерживает сабж? :)

А то получается как в анекдоте:

— Я сделал изобретение, позволяющее видеть сквозь стены!
— Но оно уже давно существует.
— Как же оно называется?
— Окно.
Всего голосов 8: ↑3 и ↓5-2
Их более 60-ти и все они описаны по ссылке, которую я привел в конце статьи: github.com/mdevils/node-jscs
Всего голосов 4: ↑4 и ↓0+4
1) JSLint — не только про ошибки.
2) Вы привели только один пример недостатка кода, который обнаруживает сабж: отсутствие пробела между function и скобкой. JSLint это отлавливает.
Всего голосов 7: ↑4 и ↓3+1
Цель моего вопроса была как раз в том, чтобы понять, какие уникальные настройки вы предоставляете в JSCS.
Предположим, есть проект, который использует JSLint. Как мне сконфигурировать(и для каких кейсов, что самое важное) JSCS, чтобы они не конфликтовали(ведь насколько я понял, у них есть дублирующий функционал)?
Комментарий пока не оценивали0
1) А с помощью утюга можно приготовить яичницу, например. Но вот испечь пирог будет проблемно.
2) Вы правы, пример с пробелом не очень-то наглядный, но идея понятна и всегда же можно перейти по урлу и мелько пробежаться глазами. Не поленитесь. Настроек очень много.
Всего голосов 3: ↑2 и ↓1+1
Более того, поддержка JSLint имеется практически у всех IDE и редакторов кода. Недостатки кода подсвечиваются во время написания, а не при запуске консольной команды.
Всего голосов 6: ↑4 и ↓2+2
Чуть выше ответ.
Комментарий пока не оценивали0


Дело времени.
Всего голосов 2: ↑2 и ↓0+2
Будем ждать для PHPStorm / WebStorm. Или уже есть?
Всего голосов 1: ↑1 и ↓0+1
Уже есть плагин.
Комментарий пока не оценивали0
Время выполнения !!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())));

})();

Всего голосов 24: ↑20 и ↓4+16
Не знаю как вы, но я пишу код для людей, мучаться должны роботы и переделать код как им нужно при минификации ;)
Всего голосов 27: ↑16 и ↓11+5
Не знаю как вы, но я согласен с Zibx. Я пишу приведение к булеву через двойное отрицание не из-за количества символов, и не понимаю, чем плоха эта запись. Прочитать !!x не сложнее, чем Boolean(x), тем более работает быстрее.
Всего голосов 21: ↑16 и ↓5+11
Мне как и вам прочитать не сложно. Любой не посвященный в JS скажет, что !!x — читается как магия; Boolean(x) — все понятно ;)
Всего голосов 18: ↑11 и ↓7+4
Для непосвящённого в JS прототипное наследование — магия, например, что ж теперь, его выкидывать? Для тех, кто программирует на Си# странно, что замыкание создаётся только на уровне функций (а for, например, новую область не создаёт), так давайте не будем пользоваться замыкамиями! Они, кстати, сами по себе для многих — магия!
Всего голосов 18: ↑15 и ↓3+12
Поэтому не стоит делать из языка элитарное сообщество, ограниченное трехметровым порогом входа. Не забывайте, что есть ряд людей, которые не пишут фуллтайм на JS, но им приходится с ним работать.
Всего голосов 11: ↑7 и ↓4+3
Не совсем понял, что вы имели в виду под «замыкание создаётся только на уровне функций (а for, например, новую область не создаёт)» — можно пример кода для ясности?
Комментарий пока не оценивали0
Классика:
for (var i = 0; i < 3; i++) {
    setTimeout(function () {
        alert(i);
    }, 100);
}
Всего голосов 1: ↑1 и ↓0+1
Я так и думал, но проверил следующим куском кода и он отработал ожидаемым образом, выведя последовательно числа от 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]();
}

Не могу понять, в чем разница между вашим кодом и моим?
Всего голосов 5: ↑1 и ↓4-3
у вас во втором цикле переменная тоже называется idx, показывается ее значение
Всего голосов 3: ↑3 и ↓0+3
Спасибо, разобрался!
Всего голосов 1: ↑1 и ↓0+1
Здесь есть тонкий момент, во втором цикле вы на самом деле используете ту же самую переменную 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]();
	}
Всего голосов 2: ↑2 и ↓0+2
Ваш код синхронный. Мой асинхронный.
Всего голосов 16: ↑7 и ↓9-2
Это чуть ли не худший ответ, который вы могли дать. Он не просто неправильный — он может создать у новичка ложное ощущение правильного понимания причины проблемы.
Всего голосов 6: ↑4 и ↓2+2
Я ответил вполне на конкретный вопрос: «Не могу понять, в чем разница между вашим кодом и моим?». Не знаю стало ли проще если я бы ответил, что в JS область видимости через var создает только функция, поэтому в следующем тике event loop значение переменной будет 3 и эта переменная будет общая для всех безымянных «замыканий» аргумента setTimeout.
Всего голосов 3: ↑2 и ↓1+1
Нет, проще бы не стало. Так как новый ответ снова как минимум некорректен в плане формулировки:
1) var никаких областей видимости не создает (с функцией или без)
2) то, будет ли функция вызываться асинхронно в другом тике или нет с обсуждаемой проблеме на самом деле не имеет никакого отношения
Всего голосов 1: ↑1 и ↓0+1
Прототипное наследование — одна из основных особенностей языка, а использование двойного отрицания для неявного приведения к булеву это использование фич языка не по назначению, побочное свойство некоторых особенностей.
Комментарий пока не оценивали0
Ну, любая поддержка кода требует понимания языка, на котором он написан. Я думаю, как bolk сказал ниже, проблема в том, что качество программистов падает, и людям становится слишком лениво разбираться в тонкостях работы с языком. Порой даже попадаются индивидумы, которые могут писать селекторы с использованием jQuery, но вытащить элемент по id на нативном JS не могут. Грустно всё это…
Всего голосов 2: ↑1 и ↓10
Вот уж не знаю, по моему все довольно очевидно, такой код вполне нормально работает в си/с++
Всего голосов 1: ↑1 и ↓0+1
Когда я первый раз встретился с ~~x, то тоже сначала растерялся, а ведь удобно.
Всего голосов 1: ↑0 и ↓1-1
Смотря для каких целей.
Я предпочитаю, например, каноничное "| 0".
Всего голосов 2: ↑1 и ↓10
Спасибо)
Комментарий пока не оценивали0
Да это просто качество программистов падает. В языке разобраться лениво, поэтому писать можно только «не смущающими новичка конструкциями».
Всего голосов 5: ↑3 и ↓2+1
В данном случае я не соглашусь с собой. Не вникал в поведение Boolean без new. Был уверен что это фабрики и что поведение может в итоге ожидаться такое, которое не смогут оптимизировать роботы. Но в яндексе при сборке кода Boolean без new скорее всего и превратится в !!.. То есть скорость исполнения будет та же. У скорости ввода есть две стороны. Обычно скорость написания кода упирается не в скорость печати. Новичкам и тем кто не знаком с js понятнее запись Boolean. С другой стороны я был уверен что абсолютно все кто касается js в яндексе среди ночи смогут рассказать всё про автоматическое приведение типов.

Да и статья о другом, думаю эту тулзу можно настроить в обратную сторону, что бы она ругалась когда вместо!!! стоит Boolean :).
Интереснее причина такого кодстайла где в js после function нужен пробел. Очень похоже на портированный PEP8.
Всего голосов 4: ↑4 и ↓0+4
Сложнее прочитать. Не вникая в тонкости неявного приведения типов запись кажется семантически бессмысленной (двойное отрицание аргумента равносильно аргументу в булевой логике, а! булевый оператор), поведение в граничных случаях не очевидно. В общем, обычный хак. Если скорость выполнения важна, то согласно правилам хорошего тона его нужно дополнять комментарием типа // fast convert to boolean, а если не важна, то просто его не использовать.
Всего голосов 1: ↑1 и ↓0+1
Попробуйте для подобных сравнений jsperf использовать — очень удобно.
jsperf.com/double-negative-vs-boolean

Кстати, мне тоже больше нравится!!! х, по сравнению с Boolean(x). Читается легче.
Всего голосов 4: ↑2 и ↓20
Отличный сервис, использую. Но когда для себя замеряю попугаев — быстрее нажать F12 чем заполнять все их поля.
Всего голосов 1: ↑1 и ↓0+1
Ну верно, ваш код стайл просто восхитителен.
Boolean(x) === false — читаемее, хоть запись и получается длиннее.
Всякие !!x, и уж точно побитовые операции на вроде вашей +new Date() или всякие ~array.indexOf(x) стоит использовать только в больших циклах, где такая экономия на спичках имеет хоть какой-то смысл.
Всего голосов 9: ↑5 и ↓4+1
Это звучит как «да ну ваше наследование через цепочку прототипов, я подключу CoffeeScript и буду писать классы».
Всего голосов 11: ↑11 и ↓0+11
Если честно, я не понял при чем здесь прототипы и классы. Разговор вообще о другом.
Всего голосов 1: ↑1 и ↓0+1
Речь о том, что логическое отрицание(!) или побитовое отрицание(~) — это просто и понятно. Это есть почти во всех языках программирования. Не знать этого довольно-таки странно для программиста. Исходя из вашего поста выше, вы пишете так:

if (Boolean(arr.length) === false) {
  ...
}

вместо

if (!arr.length) {
  ...
}

верно?
Всего голосов 12: ↑10 и ↓2+8
Вы кажется перегибаете, любой вменяемый программист будет писать !arr.length
Всего голосов 7: ↑1 и ↓6-5
Тогда почему !arr.length — является «нормальным» приведением к булеву, а !!arr.length — нет?
Всего голосов 10: ↑10 и ↓0+10
Вменяемый вообще напишет arr.length === 0, если он хочет проверить не пустой ли массив.
Всего голосов 2: ↑0 и ↓2-2
Да, мне, кстати, с недавних пор тоже стало нравиться писать так. Вообще, как по мне, практика с явным определением типов — штука правильная и хорошо дисциплинирует. Но другое дело, когда мы хотим проверить параметр объекта, возможно оно false, 0 или вовсе undefined, вот тут я все же использую if (obj.param) {}
Комментарий пока не оценивали0
Для меня 0 и undefined — это совершенно разные вещи и в одном условии я оба сразу не проверяю. Нет кейсов.
Комментарий пока не оценивали0
Конечно разные. В данном случае я рассматривал 0 как упрощенный вариант false в качестве ответа от сервера. Но так же сервер и вовсе может не установить в качестве ответа ничего. А когда мы знаем, что, возможное значение — число, пусть даже 0, то это совсем другой разговор. Так что все это частные случаи.
Комментарий пока не оценивали0
undefined вот таким словом лучше не писать никогда. undefined — не константа, его можно от скуки переопределить. === void 0 или typeof, но при typeof производится не бесплатная операция сравнения со строкой (хотя может тут работает оптимизация глобального места где хранятся все строки). Иногда ещё 'param' in obj пригождается.
Всего голосов 2: ↑2 и ↓0+2
Мне всегда казалось, может быть наивно, что сравнение итога typeof оптимизировано в движке. Правда, не то чтобы я читал исходники V8 или IonMonkey.
Всего голосов 1: ↑0 и ↓1-1
Это в общем- то и не нужно.

Достаточно посмотреть к примеру на тот asm код который v8 генерирует.

Нет желания проверять, но почти уверен что все эти сравнение будут иметь одинаковый результат. JIT он не дурак и это его работа такие вещи оптимизировать.
Комментарий пока не оценивали0
Или в функциях, которые могут позвать из циклов. Или цикл может оказаться вложенным. Ещё забавно наблюдать как функцию мэппинга объявляют в цикле. Но я полностью согласен с тем что ресурсотерпящие вещи лучше писать читаемыми.
Всего голосов 1: ↑1 и ↓0+1
Мне кажется вы лукавите. Не знаю как там у вас, но я всегда знаю, какая функция чем может быть запущена, и окажется ли она в цикле. А если мы говорим про какие-то действительно монструозные вещи, на вроде библиотек, когда и правда не ясно, что будет делать другой разработчик с вашим кодом — то тогда уж точно разницы нет — время выполнения полезного кода будет выше, чем любая экономия.
Комментарий пока не оценивали0
Я говорю про функциональный подход. Когда в функции мэппинга делают ещё мэппинг. Тут уже на 1000 иттерациях может оказаться заметна разница. Библиотеки я как раз по этой причине избегаю почти все и использую microjs если есть конкретная задача, которая точно уже решена другими. Как наглядный пример такого подхода я обычно привожу конструкцию вида $('#el1').height(). Есть случаи когда достаточно сделать document.getElementById('el1').clientHeight. И вот в этом случае я прошу пройти по стеку того что делает жквери, что бы в итоге вызвать эту конструкцию. Но это важно в основном при отрисовке больших списков данных или когда мы пишем веб-приложение и весомая часть модели живёт в браузере. В случае если нам надо повесить событие на клик кнопки logout — тут действительно можно сделать это чем угодно. Но при этом событие mousemove использовать обёрнутое любой библиотекой — всё равно крайне не желательно, если мы хотим сделать плавную анимацию. Что-то я разошелся, оптимизация у меня — больная тема. :)
Всего голосов 1: ↑1 и ↓0+1
Boolean(x) === false
Зачем? Неужели так читаемее?
Всего голосов 3: ↑3 и ↓0+3
Я вам больше скажу, в таких местах даже читаемее использовать Йода-стайл на вроде false === Boolean(x)
Только не нужно кидаться тухлыми помидорами, не попробовав на практике такой подход. Это мы тут с вами снипеты в 2 строки разбираем, на реальном же коде особенности оформления уже играют большую роль в понимании.
Всего голосов 1: ↑0 и ↓1-1
«Йода-стайл», как вы его назвали, родился вовсе не из читаемости. Соглашение «константа слева» спасает от ситуации, когда программист пропускает одно равно и получает if (a = false) вместо if (a == false). В вашем же случае «false === Boolean(x)» это соглашение лишнее, да и вообще вся конструкция должна умереть.
Всего голосов 2: ↑2 и ↓0+2
Не сочтите за грубость, но вы же мне просто глаза открыли. Тем более, что про указанное вами соглашение можно не беспокоиться в рамках JS, так как if (x = 2) {} вызывает ошибку. Я же не заставляю никого писать так, как нравится мне, и как пишет команда автора из Яндекса, а у них-то наверное больше аргументов на счет явного приведения типов.
Всего голосов 1: ↑0 и ↓1-1
НЛО прилетело и опубликовало эту надпись здесь
Вот теперь можно констатировать, что я, кажется, сошел с ума. Я серьезно. Просто вот сейчас я не могу объяснить, как я такую ахинею мог написать, и как я так пришел к тому, к чему пришел. Стыдоба.
Всего голосов 3: ↑3 и ↓0+3
Дело скорее всего не в производительности, а в однозначности поведения. Чтобы код отрабатывал максимально одинаково на всех существующих известных, неизвестных и теоретически возможных платформах…
Комментарий пока не оценивали0
От этого спасут только тесты. Я вот был уверен что Boolean возвращает не примитив, а объект как в случае с new Boolean(false). И у меня есть уже немного опыта js, и потому я проверил и теперь знаю, а те кто делают код ревью могут не знать такой тонкости.
Проверить объект это или примитив можно присвоив свойства объекта, а потом взяв его.
Комментарий пока не оценивали0
Микробенчмаркинг зло. Он показывает не цифры скорости какие-то цифры. JIT браузера очень интересно оптимизирует код.
Пропустите код выше через V8 со специальными флагами посмотрите на ASM код который получится. Будете удивлены)
Комментарий пока не оценивали0
А нет в планах пойти дальше и не просто выводить ошибки, а делать авто форматирование кода? Пиши как хочешь, а хук на pre-commit приводит весь код к единому код стайлу.

P.S. Сам пробовал jsbeautifier и esformatter, увы оба обладают своими недостатками, последний так совсем коверкает исходный файл.
Всего голосов 6: ↑6 и ↓0+6
В планах этого нет. Цель проекта в том, чтобы помочь привыкнуть и с помощью CI — контролировать.
Всего голосов 5: ↑2 и ↓3-1
Очень жаль.
Всего голосов 8: ↑6 и ↓2+4
И мне тоже. Новая команда — и сразу обучение новому стилю, хотя логика от этого не меняется. В PHPStorm видел при коммите возможность переформатировать код автоматически, только вроде это к php относится и, если и к JS, то изменения типа !!x -> Boolean(x) не делает.
Комментарий пока не оценивали0
Открывая статью надеялся, что это не про другой JSLint, а про автоматическое форматирование кода — настроил свои правила, и при чекауте получаешь JS-код в своём любимом стиле, а при коммите он переформатируется в принятый в команде.
Зачем мне сообщение о забытом пробеле и облом коммита? Компьютер железный — пусть он и расставляет (не)нужные пробелы.
Всего голосов 21: ↑19 и ↓2+17
Это был бы идеальный инструмент!
Всего голосов 1: ↑1 и ↓0+1
WebStorm же это умеет делать. Один раз настроил правила и всё ок.
Комментарий пока не оценивали0
не умеет(на сколько я знаю). Он умеет форматировать код так, как вам нужно.
Но тут человек хочет получить Boolean(x), а видеть !!x, например
Комментарий пока не оценивали0
Тогда нужно и обратное преобразование делать (при пуллиге кода из репозитория). Иначе смысл теряется.
Всего голосов 1: ↑1 и ↓0+1
1. Выбрать одно лучшее IDE (мы, например, выбрали IDEA)
2. Использовать дефолтные настройки и не лезть со своим Code Style (мы просто жмем Ctrl + Alt + L, срабатывает авто-форматирование и стиль у всех один)
Всего голосов 4: ↑4 и ↓0+4
3. Continuous Integration.

Тут и начинаются проблемы.
Всего голосов 5: ↑2 и ↓3-1
Какие?
Всего голосов 13: ↑11 и ↓2+9
меня бы очень расстроило если бы кто-то начал мне говорить какую IDE использовать
Всего голосов 9: ↑7 и ↓2+5
Одну IDE использовать совсем не обязательно, есть тот же editorconfig, например.
Всего голосов 1: ↑1 и ↓0+1
Неужели в вашей любомй IDE нет авто-форматирования кода?
Всего голосов 1: ↑0 и ↓1-1
может и есть, но в комментарии, на который я отвечал, предлагали всей командой перейти на одну IDE
Всего голосов 1: ↑1 и ↓0+1
Ммм, да, я почему-то прочитал его как «настроить свои IDE единообразно, согласно code style команды и пользоваться авто-форматированием». Удивляюсь теперь, как так вышло.
Всего голосов 2: ↑2 и ↓0+2
НЛО прилетело и опубликовало эту надпись здесь
И, может быть, имеет смысл написать средство форматирования кода и использовать его повсеместно?


Дописать clang-format, например, сейчас там уже есть минимальный задел на js. Тем более, такая вещь нужна всему Яндексу.
Комментарий пока не оценивали0
НЛО прилетело и опубликовало эту надпись здесь
Звиняйте, не разобрался, думал скрипт для баша…
Комментарий пока не оценивали0
Вот смотрю я на эту форму фидбека и не могу придумать, какая там может быть нетривиальная логика внутри. Поделитесь, что она делает хоть, кроме очевидной отправки фидбека?
Всего голосов 8: ↑7 и ↓1+6
Рейтинг там примеру со звёздами, который можно попариться при наведении мышки красиво анимировать. Форма может увеличивается при наборе текста. Анимация при добавлении какая-нибудь.

Всегда легко посмотреть на что-нибудь вроде твиттера и хмыкнуть «ха, бложик на 140 знаков».
Всего голосов 3: ↑0 и ↓3-3
Так я же не хмыкаю. Наоборот, хочу постичь и приобщиться. Тем более, что фраза «нетривиальная логика» подразумевает не просто анимацию звездочек
Комментарий пока не оценивали0
А не было варианта просто настроить инспекции в каком-нибудь ВебШторме? Или том же Виме/Емаксе, я ими сам не пользуюсь, но раз они осиливают подсветку, значит с синтаксическими конструкциями работать в принципе можно.
Всего голосов 2: ↑2 и ↓0+2
Если честно, размер проекта на гитхабе поистине пугает. я бы ограничился примитивным скриптом, выдающим ошибки в типичном формате компиляторов <path>:<line>:<message>. Vim (syntactic), Emacs (compile/recompile, flymake) и ST (из коробки) прекрасно понимаю такой формат и позволяют прыгать к исходникам и выделать строки с ошибками.
Комментарий пока не оценивали0
Очень хорошо, что осведомили. Кабы карма Ваша не была и без того заплюсована мною — беспременно заплюсовал бы её сегодня.

А не то, видите ли, я до сих пор сидел на JSHint 2.x, потому что произошедшие в 3.x перемены (отказ от проверки стиля) ну никак не мог принять.

Конечно, теперь (когда есть отдельный стилепроверщик) — это неплохо. Есть куда убежать с JSHintовской проверки стиля.

(Хорошо бы кто-нибудь #138 пофиксил, конечно; но и без того очень, очень неплохо.)
Всего голосов 5: ↑4 и ↓1+3
НЛО прилетело и опубликовало эту надпись здесь
Кода довольно много, что бы пролистать, поэтому проще спросить — проводится ли семантический анализ, посроение AST? Если нет, почему недостаточно регулярных выражений, на которые способно большинство полноценных текстовых редакторов, ну или sed awk? Какого рода парсинг проводится, если не секрет?
Комментарий пока не оценивали0
Парсинг и построение AST с помощью esprima.
Комментарий пока не оценивали0
Вызывает уважение. Тогда по обмену опытом, мой сейчас любимый язык Go включает такого рода утилиту форматирования в коробочной поставке. Конфигурация не предусматривается, поскольку полагается что весь код на Go должен быть написан единообразно. Зато присутствует зачаточная возможность символьной трансформации, то есть например можно задать правило 2*x -> x+x
Комментарий пока не оценивали0
Классика жанра:
image
Всего голосов 9: ↑0 и ↓9-9
Почему бы не сделать описание правил форматирования на основе BNF?
Всего голосов 3: ↑2 и ↓1+1
Что-то я не понял.
Есть команда, в которой принят некий стиль. Там же есть, видимо, специально обученный человек, который высматривает пробелы и грепает восклицательные знаки. Сам расставлять пробелы он не умеет, просто рефьюзит коммит. Вы (автор статьи) написали утилиту, которая заменяет этого человека. И команде ничего не говорили… Мне это как-то дико. Или в команде тоже используется какой-то инструмент, но вы решили написать свой? Или в команде у каждого свои костыли имеются? Я работал в разных командах и что-то не могу представить вашу ситуацию.
Спрашиваю потому, что уже не первый раз рассказы о том, как работает Яндекс, вводят меня в недоумение.
Всего голосов 9: ↑1 и ↓8-7
В каких-то странных командах вы работали.
Процедуру код ревью себе представляете? Я, на всякий случай расскажу. Вы пишете код, ваши коллеги его смотрят, пишут замечания, вы исправляете (ну или обосновываете, что написали как надо) код в соответствии с замечаниями, отправляете на повторное ревью и т.д…
То есть не нужен специальный человек для этого.
А автору статьи было сложно привыкнуть к новому для него стилю кода, и для помощи себе он написал утилиту, которая оказалась полезной множеству людей.
То что общепринятые практики разработки ПО вводят вас в недоумение, то у меня для вас плохие новости.
Всего голосов 2: ↑2 и ↓0+2
Во-первых.
Мне всегда попадались люди, которые обнаруживали ошибки типа «это не заработает на python 2.3», «здесь лучше использовать другую структуру данных», «у нас принято писать комментарии на английском языке»… К пробелам и деталям типа «типов в языках со слабой типизацией» либо не привязывались, либо проверяли линтерами и прочими инструментами.
Во-вторых.
Мне попадались команды, где разработанные инструменты тут же становились общим достоянием. Макросы к редакторам, анализаторы логов, и даже форматировалки исходников. Все эти вещи разрабатывались совместно. И мне действительно трудно представить противоположную ситуацию. Почему человек вынужден делать для себя очевидный инструмент? Почему, сделав его, он не предлагает его команде? Ждёт, когда каждый сделает себе свой? Я действительно не понимаю логику такого поведения.
Комментарий пока не оценивали0
К пробелам и деталям типа «типов в языках со слабой типизацией» либо не привязывались, .

Ну, что не привязывались — в этом ничего хорошего нет, я сторонник строго придерживаться стайл-гайда.
либо проверяли линтерами и прочими инструментами

Вы ведь понимаете, что инструмент написали потому что подходящего не было?

Мне попадались команды, где разработанные инструменты тут же становились общим достоянием.

Статью читали? В статье явно написано, что с коллегами поделился. А теперь и со всеми желающими за пределами компании (что гораздо важнее, как мне кажется).

Вы выглядите приятным, разумным человеком, но в первом комментарии какую-то ерунду написали, честное слово.
Комментарий пока не оценивали0
Недавно наткнулся на ESLint. Проект позиционирует себя как модульная альтернатива jslint/jshint, где каждый может легко добавлять свои правила. К сожалению пока руки не дошли попробовать, но было бы интересно сравнить и узнать мнение тех кто пользовался
Всего голосов 2: ↑2 и ↓0+2
Уже много месяцев пользуюсь вашей разработкой в виде grunt-плагина grunt-jscs-checker во всех проектах. Ужасно доволен, спасибо вам огромное!
Не прочитал все коментарии, возможно уже спрашивали. Планируется ли сделать удобный интерфейс для генерации конфига jscs? Чтобы не читать весь ридми с последующей копипастой, а прощелкивать слайды, а в конце копировать конфиг?
Всего голосов 2: ↑2 и ↓0+2
Нет, простого интерфейса для конфигурации нет. Но если вы разработаете, мы будем счастливы его принять и развивать.
Комментарий пока не оценивали0
Ок, попробую набросать прототип на gh-pages в форке к вашему репу. Вопрос в том, будут ли его поддерживать, при добавлении новых правил, чтобы держать в актуальном состоянии…
Всего голосов 1: ↑1 и ↓0+1
Если будет удобно и понятно реализовано, то пользователи смогут контрибьютить с учетом этой страницы.
Комментарий пока не оценивали0
Судя по камментам мало кто читал гитхаб и мало кто понял зачем данная итилита. Печально.
Комментарий пока не оценивали0
У нас в компании царят формат-фашизм и граммар-нацизм, поэтому JSCS наряду с JSHint стоит на хуках в репозиториях.
Нестильный код не пройдёт!

Спасибо за такую потрясающую утилиту.
Комментарий пока не оценивали0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Показать лучшие за всё время
Разблокировать темную тему

Истории

Ваш аккаунт

Разделы

Информация

Услуги

Техническая поддержка
© 2006–2024, Habr