mdevils 21 апр 2014 в 12:23

JSCS: JavaScript Code Style

3 мин

59K

JavaScript *

+115

118

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

lolmaus 21 апр 2014 в 12:33

Чем JSLint не устроил-то?

zloylos 21 апр 2014 в 12:39

Все просто: JSLint про ошибки, JSCS про код-стайл.

xamd 21 апр 2014 в 12:46

Не могли бы вы привести больше примеров? Пока смутно понимаю, в чём принципиальное отличие. И в JSLint, и в вашем проекте можно настроить, например, необходимость фигурных скобок у if .. else, однако это не «ошибка», как вы пишете, а именно стиль оформления кода.

mdevils 21 апр 2014 в 13:04

JSLint не покрывает требований по кодстайлу наших проектов. Да и не развивается он. Если бы и развивался, то архитектура в JSLint настолько ужасно, что контрибьютить — это последнее, что хочется.

lolmaus 21 апр 2014 в 13:17

Ну так может вы приведете список стилевых правил, которые поддерживает сабж? :)

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

— Я сделал изобретение, позволяющее видеть сквозь стены!
— Но оно уже давно существует.
— Как же оно называется?
— Окно.

mdevils 21 апр 2014 в 13:18

Их более 60-ти и все они описаны по ссылке, которую я привел в конце статьи: github.com/mdevils/node-jscs

lolmaus 21 апр 2014 в 12:59

1) JSLint — не только про ошибки.
2) Вы привели только один пример недостатка кода, который обнаруживает сабж: отсутствие пробела между function и скобкой. JSLint это отлавливает.

xamd 21 апр 2014 в 13:09

Цель моего вопроса была как раз в том, чтобы понять, какие уникальные настройки вы предоставляете в JSCS.
Предположим, есть проект, который использует JSLint. Как мне сконфигурировать(и для каких кейсов, что самое важное) JSCS, чтобы они не конфликтовали(ведь насколько я понял, у них есть дублирующий функционал)?

zloylos 21 апр 2014 в 13:21

1) А с помощью утюга можно приготовить яичницу, например. Но вот испечь пирог будет проблемно.
2) Вы правы, пример с пробелом не очень-то наглядный, но идея понятна и всегда же можно перейти по урлу и мелько пробежаться глазами. Не поленитесь. Настроек очень много.

lolmaus 21 апр 2014 в 13:03

Более того, поддержка JSLint имеется практически у всех IDE и редакторов кода. Недостатки кода подсвечиваются во время написания, а не при запуске консольной команды.

mdevils 21 апр 2014 в 13:04

Чуть выше ответ.

mdevils 21 апр 2014 в 13:06

Дело времени.

TurtleSun 22 апр 2014 в 13:10

Будем ждать для PHPStorm / WebStorm. Или уже есть?

Roger 22 апр 2014 в 14:12

Пока нет, но есть задача, за которую можно проголосовать: youtrack.jetbrains.com/issue/WEB-10591

EASemashko 29 сен 2015 в 16:19

Уже есть плагин.

Zibx 21 апр 2014 в 13:05

Время выполнения !!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())));

})();

azproduction 21 апр 2014 в 13:10

Не знаю как вы, но я пишу код для людей, мучаться должны роботы и переделать код как им нужно при минификации ;)

xamd 21 апр 2014 в 13:15

Не знаю как вы, но я согласен с Zibx. Я пишу приведение к булеву через двойное отрицание не из-за количества символов, и не понимаю, чем плоха эта запись. Прочитать !!x не сложнее, чем Boolean(x), тем более работает быстрее.

azproduction 21 апр 2014 в 13:21

Мне как и вам прочитать не сложно. Любой не посвященный в JS скажет, что !!x — читается как магия; Boolean(x) — все понятно ;)

bolk 21 апр 2014 в 13:24

Для непосвящённого в JS прототипное наследование — магия, например, что ж теперь, его выкидывать? Для тех, кто программирует на Си# странно, что замыкание создаётся только на уровне функций (а for, например, новую область не создаёт), так давайте не будем пользоваться замыкамиями! Они, кстати, сами по себе для многих — магия!

azproduction 21 апр 2014 в 13:48

Поэтому не стоит делать из языка элитарное сообщество, ограниченное трехметровым порогом входа. Не забывайте, что есть ряд людей, которые не пишут фуллтайм на JS, но им приходится с ним работать.

impwx 21 апр 2014 в 15:19

Не совсем понял, что вы имели в виду под «замыкание создаётся только на уровне функций (а for, например, новую область не создаёт)» — можно пример кода для ясности?

azproduction 21 апр 2014 в 15:26

Классика:

for (var i = 0; i < 3; i++) {
    setTimeout(function () {
        alert(i);
    }, 100);
}

impwx 21 апр 2014 в 15:35

Я так и думал, но проверил следующим куском кода и он отработал ожидаемым образом, выведя последовательно числа от 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]();
}

Не могу понять, в чем разница между вашим кодом и моим?

Pozadi 21 апр 2014 в 16:00

у вас во втором цикле переменная тоже называется idx, показывается ее значение

impwx 21 апр 2014 в 17:22

Спасибо, разобрался!

Saladin 21 апр 2014 в 16:02

Здесь есть тонкий момент, во втором цикле вы на самом деле используете ту же самую переменную 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]();
	}

azproduction 21 апр 2014 в 16:07

Ваш код синхронный. Мой асинхронный.

Regis 21 апр 2014 в 20:25

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

azproduction 22 апр 2014 в 06:22

Я ответил вполне на конкретный вопрос: «Не могу понять, в чем разница между вашим кодом и моим?». Не знаю стало ли проще если я бы ответил, что в JS область видимости через var создает только функция, поэтому в следующем тике event loop значение переменной будет 3 и эта переменная будет общая для всех безымянных «замыканий» аргумента setTimeout.

Regis 23 апр 2014 в 15:46

Нет, проще бы не стало. Так как новый ответ снова как минимум некорректен в плане формулировки:
1) var никаких областей видимости не создает (с функцией или без)
2) то, будет ли функция вызываться асинхронно в другом тике или нет с обсуждаемой проблеме на самом деле не имеет никакого отношения

VolCh 22 апр 2014 в 10:06

Прототипное наследование — одна из основных особенностей языка, а использование двойного отрицания для неявного приведения к булеву это использование фич языка не по назначению, побочное свойство некоторых особенностей.

xamd 21 апр 2014 в 13:28

Ну, любая поддержка кода требует понимания языка, на котором он написан. Я думаю, как bolk сказал ниже, проблема в том, что качество программистов падает, и людям становится слишком лениво разбираться в тонкостях работы с языком. Порой даже попадаются индивидумы, которые могут писать селекторы с использованием jQuery, но вытащить элемент по id на нативном JS не могут. Грустно всё это…

hell0w0rd 21 апр 2014 в 15:45

Вот уж не знаю, по моему все довольно очевидно, такой код вполне нормально работает в си/с++

TurtleSun 22 апр 2014 в 13:12

Когда я первый раз встретился с ~~x, то тоже сначала растерялся, а ведь удобно.

MuLLtiQ 22 апр 2014 в 13:46

Смотря для каких целей.
Я предпочитаю, например, каноничное "| 0".

TurtleSun 22 апр 2014 в 16:31

Спасибо)

bolk 21 апр 2014 в 13:22

Да это просто качество программистов падает. В языке разобраться лениво, поэтому писать можно только «не смущающими новичка конструкциями».

Anarchist 22 апр 2014 в 11:16

Почему-то сразу вспомнилось: www.99-bottles-of-beer.net/language-perl-737.html

Zibx 21 апр 2014 в 13:27

В данном случае я не соглашусь с собой. Не вникал в поведение Boolean без new. Был уверен что это фабрики и что поведение может в итоге ожидаться такое, которое не смогут оптимизировать роботы. Но в яндексе при сборке кода Boolean без new скорее всего и превратится в !!.. То есть скорость исполнения будет та же. У скорости ввода есть две стороны. Обычно скорость написания кода упирается не в скорость печати. Новичкам и тем кто не знаком с js понятнее запись Boolean. С другой стороны я был уверен что абсолютно все кто касается js в яндексе среди ночи смогут рассказать всё про автоматическое приведение типов.

Да и статья о другом, думаю эту тулзу можно настроить в обратную сторону, что бы она ругалась когда вместо!!! стоит Boolean :).
Интереснее причина такого кодстайла где в js после function нужен пробел. Очень похоже на портированный PEP8.

VolCh 22 апр 2014 в 10:02

Сложнее прочитать. Не вникая в тонкости неявного приведения типов запись кажется семантически бессмысленной (двойное отрицание аргумента равносильно аргументу в булевой логике, а! булевый оператор), поведение в граничных случаях не очевидно. В общем, обычный хак. Если скорость выполнения важна, то согласно правилам хорошего тона его нужно дополнять комментарием типа // fast convert to boolean, а если не важна, то просто его не использовать.

the_ghost 21 апр 2014 в 13:20

Попробуйте для подобных сравнений jsperf использовать — очень удобно.
jsperf.com/double-negative-vs-boolean

Кстати, мне тоже больше нравится!!! х, по сравнению с Boolean(x). Читается легче.

Zibx 21 апр 2014 в 13:32

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

radist2s 21 апр 2014 в 13:21

Ну верно, ваш код стайл просто восхитителен.
Boolean(x) === false — читаемее, хоть запись и получается длиннее.
Всякие !!x, и уж точно побитовые операции на вроде вашей +new Date() или всякие ~array.indexOf(x) стоит использовать только в больших циклах, где такая экономия на спичках имеет хоть какой-то смысл.

xamd 21 апр 2014 в 13:29

Это звучит как «да ну ваше наследование через цепочку прототипов, я подключу CoffeeScript и буду писать классы».

radist2s 21 апр 2014 в 13:38

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

xamd 21 апр 2014 в 13:49

Речь о том, что логическое отрицание(!) или побитовое отрицание(~) — это просто и понятно. Это есть почти во всех языках программирования. Не знать этого довольно-таки странно для программиста. Исходя из вашего поста выше, вы пишете так:

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

вместо

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

верно?

radist2s 21 апр 2014 в 13:51

Вы кажется перегибаете, любой вменяемый программист будет писать !arr.length

xamd 21 апр 2014 в 13:52

Тогда почему !arr.length — является «нормальным» приведением к булеву, а !!arr.length — нет?

VolCh 22 апр 2014 в 10:12

Вменяемый вообще напишет arr.length === 0, если он хочет проверить не пустой ли массив.

mdevils 21 апр 2014 в 13:54

Я обычно пишу:

if (arr.length === 0) {
  ...
}

radist2s 21 апр 2014 в 14:04

Да, мне, кстати, с недавних пор тоже стало нравиться писать так. Вообще, как по мне, практика с явным определением типов — штука правильная и хорошо дисциплинирует. Но другое дело, когда мы хотим проверить параметр объекта, возможно оно false, 0 или вовсе undefined, вот тут я все же использую if (obj.param) {}

mdevils 21 апр 2014 в 14:06

Для меня 0 и undefined — это совершенно разные вещи и в одном условии я оба сразу не проверяю. Нет кейсов.

radist2s 21 апр 2014 в 14:23

Конечно разные. В данном случае я рассматривал 0 как упрощенный вариант false в качестве ответа от сервера. Но так же сервер и вовсе может не установить в качестве ответа ничего. А когда мы знаем, что, возможное значение — число, пусть даже 0, то это совсем другой разговор. Так что все это частные случаи.

Zibx 21 апр 2014 в 14:53

undefined вот таким словом лучше не писать никогда. undefined — не константа, его можно от скуки переопределить. === void 0 или typeof, но при typeof производится не бесплатная операция сравнения со строкой (хотя может тут работает оптимизация глобального места где хранятся все строки). Иногда ещё 'param' in obj пригождается.

Mithgol 21 апр 2014 в 16:24

Мне всегда казалось, может быть наивно, что сравнение итога typeof оптимизировано в движке. Правда, не то чтобы я читал исходники V8 или IonMonkey.

Eternalko 1 окт 2014 в 20:51

Это в общем- то и не нужно.

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

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

Zibx 21 апр 2014 в 13:31

Или в функциях, которые могут позвать из циклов. Или цикл может оказаться вложенным. Ещё забавно наблюдать как функцию мэппинга объявляют в цикле. Но я полностью согласен с тем что ресурсотерпящие вещи лучше писать читаемыми.

radist2s 21 апр 2014 в 13:38

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

Zibx 21 апр 2014 в 13:54

Я говорю про функциональный подход. Когда в функции мэппинга делают ещё мэппинг. Тут уже на 1000 иттерациях может оказаться заметна разница. Библиотеки я как раз по этой причине избегаю почти все и использую microjs если есть конкретная задача, которая точно уже решена другими. Как наглядный пример такого подхода я обычно привожу конструкцию вида $('#el1').height(). Есть случаи когда достаточно сделать document.getElementById('el1').clientHeight. И вот в этом случае я прошу пройти по стеку того что делает жквери, что бы в итоге вызвать эту конструкцию. Но это важно в основном при отрисовке больших списков данных или когда мы пишем веб-приложение и весомая часть модели живёт в браузере. В случае если нам надо повесить событие на клик кнопки logout — тут действительно можно сделать это чем угодно. Но при этом событие mousemove использовать обёрнутое любой библиотекой — всё равно крайне не желательно, если мы хотим сделать плавную анимацию. Что-то я разошелся, оптимизация у меня — больная тема. :)

MuLLtiQ 21 апр 2014 в 13:51

Boolean(x) === false
Зачем? Неужели так читаемее?

radist2s 21 апр 2014 в 13:56

Я вам больше скажу, в таких местах даже читаемее использовать Йода-стайл на вроде false === Boolean(x)
Только не нужно кидаться тухлыми помидорами, не попробовав на практике такой подход. Это мы тут с вами снипеты в 2 строки разбираем, на реальном же коде особенности оформления уже играют большую роль в понимании.

bolk 21 апр 2014 в 19:10

«Йода-стайл», как вы его назвали, родился вовсе не из читаемости. Соглашение «константа слева» спасает от ситуации, когда программист пропускает одно равно и получает if (a = false) вместо if (a == false). В вашем же случае «false === Boolean(x)» это соглашение лишнее, да и вообще вся конструкция должна умереть.

radist2s 21 апр 2014 в 20:10

Не сочтите за грубость, но вы же мне просто глаза открыли. Тем более, что про указанное вами соглашение можно не беспокоиться в рамках JS, так как if (x = 2) {} вызывает ошибку. Я же не заставляю никого писать так, как нравится мне, и как пишет команда автора из Яндекса, а у них-то наверное больше аргументов на счет явного приведения типов.

НЛО прилетело и опубликовало эту надпись здесь

radist2s 21 апр 2014 в 22:04

Вот теперь можно констатировать, что я, кажется, сошел с ума. Я серьезно. Просто вот сейчас я не могу объяснить, как я такую ахинею мог написать, и как я так пришел к тому, к чему пришел. Стыдоба.

EvilPartisan 21 апр 2014 в 16:17

Дело скорее всего не в производительности, а в однозначности поведения. Чтобы код отрабатывал максимально одинаково на всех существующих известных, неизвестных и теоретически возможных платформах…

Zibx 21 апр 2014 в 16:52

От этого спасут только тесты. Я вот был уверен что Boolean возвращает не примитив, а объект как в случае с new Boolean(false). И у меня есть уже немного опыта js, и потому я проверил и теперь знаю, а те кто делают код ревью могут не знать такой тонкости.
Проверить объект это или примитив можно присвоив свойства объекта, а потом взяв его.

Eternalko 30 сен 2014 в 17:26

Микробенчмаркинг зло. Он показывает не цифры скорости какие-то цифры. JIT браузера очень интересно оптимизирует код.
Пропустите код выше через V8 со специальными флагами посмотрите на ASM код который получится. Будете удивлены)

RubaXa 21 апр 2014 в 13:28

А нет в планах пойти дальше и не просто выводить ошибки, а делать авто форматирование кода? Пиши как хочешь, а хук на pre-commit приводит весь код к единому код стайлу.

P.S. Сам пробовал jsbeautifier и esformatter, увы оба обладают своими недостатками, последний так совсем коверкает исходный файл.

mdevils 21 апр 2014 в 13:39

В планах этого нет. Цель проекта в том, чтобы помочь привыкнуть и с помощью CI — контролировать.

RubaXa 21 апр 2014 в 13:41

Очень жаль.

TurtleSun 22 апр 2014 в 13:21

И мне тоже. Новая команда — и сразу обучение новому стилю, хотя логика от этого не меняется. В PHPStorm видел при коммите возможность переформатировать код автоматически, только вроде это к php относится и, если и к JS, то изменения типа !!x -> Boolean(x) не делает.

z6Dabrata 22 апр 2014 в 02:55

Есть проект, который может форматировать код, количество настроек там правда пока невелико.

github.com/jedmao/codepainter

Goodkat 21 апр 2014 в 13:30

Открывая статью надеялся, что это не про другой JSLint, а про автоматическое форматирование кода — настроил свои правила, и при чекауте получаешь JS-код в своём любимом стиле, а при коммите он переформатируется в принятый в команде.
Зачем мне сообщение о забытом пробеле и облом коммита? Компьютер железный — пусть он и расставляет (не)нужные пробелы.

crusat 21 апр 2014 в 14:32

Это был бы идеальный инструмент!

dos 21 апр 2014 в 15:03

WebStorm же это умеет делать. Один раз настроил правила и всё ок.

hell0w0rd 21 апр 2014 в 15:47

не умеет(на сколько я знаю). Он умеет форматировать код так, как вам нужно.
Но тут человек хочет получить Boolean(x), а видеть !!x, например

z6Dabrata 23 апр 2014 в 05:49

[deleted]

Nordvind 22 апр 2014 в 11:15

Тогда нужно и обратное преобразование делать (при пуллиге кода из репозитория). Иначе смысл теряется.

bakhirev 21 апр 2014 в 13:57

1. Выбрать одно лучшее IDE (мы, например, выбрали IDEA)
2. Использовать дефолтные настройки и не лезть со своим Code Style (мы просто жмем Ctrl + Alt + L, срабатывает авто-форматирование и стиль у всех один)

mdevils 21 апр 2014 в 13:58

3. Continuous Integration.

Тут и начинаются проблемы.

MuLLtiQ 21 апр 2014 в 14:54

Какие?

Pozadi 21 апр 2014 в 16:06

меня бы очень расстроило если бы кто-то начал мне говорить какую IDE использовать

Blah 21 апр 2014 в 22:14

Одну IDE использовать совсем не обязательно, есть тот же editorconfig, например.

asavin 22 апр 2014 в 11:50

Неужели в вашей любомй IDE нет авто-форматирования кода?

Pozadi 22 апр 2014 в 11:55

может и есть, но в комментарии, на который я отвечал, предлагали всей командой перейти на одну IDE

asavin 22 апр 2014 в 12:01

Ммм, да, я почему-то прочитал его как «настроить свои IDE единообразно, согласно code style команды и пользоваться авто-форматированием». Удивляюсь теперь, как так вышло.

НЛО прилетело и опубликовало эту надпись здесь

roman_kashitsyn 21 апр 2014 в 16:12

И, может быть, имеет смысл написать средство форматирования кода и использовать его повсеместно?

Дописать clang-format, например, сейчас там уже есть минимальный задел на js. Тем более, такая вещь нужна всему Яндексу.

Psychosynthesis 21 апр 2014 в 14:25

А для виндузятников экзешник?

НЛО прилетело и опубликовало эту надпись здесь

Psychosynthesis 21 апр 2014 в 16:15

Звиняйте, не разобрался, думал скрипт для баша…

EvilBeaver 21 апр 2014 в 14:36

Вот смотрю я на эту форму фидбека и не могу придумать, какая там может быть нетривиальная логика внутри. Поделитесь, что она делает хоть, кроме очевидной отправки фидбека?

furyk 21 апр 2014 в 15:56

Рейтинг там примеру со звёздами, который можно попариться при наведении мышки красиво анимировать. Форма может увеличивается при наборе текста. Анимация при добавлении какая-нибудь.

Всегда легко посмотреть на что-нибудь вроде твиттера и хмыкнуть «ха, бложик на 140 знаков».

EvilBeaver 21 апр 2014 в 17:25

Так я же не хмыкаю. Наоборот, хочу постичь и приобщиться. Тем более, что фраза «нетривиальная логика» подразумевает не просто анимацию звездочек

leventov 21 апр 2014 в 15:55

А не было варианта просто настроить инспекции в каком-нибудь ВебШторме? Или том же Виме/Емаксе, я ими сам не пользуюсь, но раз они осиливают подсветку, значит с синтаксическими конструкциями работать в принципе можно.

roman_kashitsyn 21 апр 2014 в 16:17

Если честно, размер проекта на гитхабе поистине пугает. я бы ограничился примитивным скриптом, выдающим ошибки в типичном формате компиляторов <path>:<line>:<message>. Vim (syntactic), Emacs (compile/recompile, flymake) и ST (из коробки) прекрасно понимаю такой формат и позволяют прыгать к исходникам и выделать строки с ошибками.

Mithgol 21 апр 2014 в 16:30

Очень хорошо, что осведомили. Кабы карма Ваша не была и без того заплюсована мною — беспременно заплюсовал бы её сегодня.

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

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

(Хорошо бы кто-нибудь #138 пофиксил, конечно; но и без того очень, очень неплохо.)

НЛО прилетело и опубликовало эту надпись здесь

uvelichitel 21 апр 2014 в 17:27

Кода довольно много, что бы пролистать, поэтому проще спросить — проводится ли семантический анализ, посроение AST? Если нет, почему недостаточно регулярных выражений, на которые способно большинство полноценных текстовых редакторов, ну или sed awk? Какого рода парсинг проводится, если не секрет?

mdevils 21 апр 2014 в 18:28

Парсинг и построение AST с помощью esprima.

uvelichitel 21 апр 2014 в 19:23

Вызывает уважение. Тогда по обмену опытом, мой сейчас любимый язык Go включает такого рода утилиту форматирования в коробочной поставке. Конфигурация не предусматривается, поскольку полагается что весь код на Go должен быть написан единообразно. Зато присутствует зачаточная возможность символьной трансформации, то есть например можно задать правило 2*x -> x+x

Ataraxer 21 апр 2014 в 20:22

Классика жанра:

monolithed 22 апр 2014 в 04:20

Почему бы не сделать описание правил форматирования на основе BNF?

michurin 22 апр 2014 в 06:45

Что-то я не понял.
Есть команда, в которой принят некий стиль. Там же есть, видимо, специально обученный человек, который высматривает пробелы и грепает восклицательные знаки. Сам расставлять пробелы он не умеет, просто рефьюзит коммит. Вы (автор статьи) написали утилиту, которая заменяет этого человека. И команде ничего не говорили… Мне это как-то дико. Или в команде тоже используется какой-то инструмент, но вы решили написать свой? Или в команде у каждого свои костыли имеются? Я работал в разных командах и что-то не могу представить вашу ситуацию.
Спрашиваю потому, что уже не первый раз рассказы о том, как работает Яндекс, вводят меня в недоумение.

Shoonoise 22 апр 2014 в 15:21

В каких-то странных командах вы работали.
Процедуру код ревью себе представляете? Я, на всякий случай расскажу. Вы пишете код, ваши коллеги его смотрят, пишут замечания, вы исправляете (ну или обосновываете, что написали как надо) код в соответствии с замечаниями, отправляете на повторное ревью и т.д…
То есть не нужен специальный человек для этого.
А автору статьи было сложно привыкнуть к новому для него стилю кода, и для помощи себе он написал утилиту, которая оказалась полезной множеству людей.
То что общепринятые практики разработки ПО вводят вас в недоумение, то у меня для вас плохие новости.

michurin 22 апр 2014 в 16:28

Во-первых.
Мне всегда попадались люди, которые обнаруживали ошибки типа «это не заработает на python 2.3», «здесь лучше использовать другую структуру данных», «у нас принято писать комментарии на английском языке»… К пробелам и деталям типа «типов в языках со слабой типизацией» либо не привязывались, либо проверяли линтерами и прочими инструментами.
Во-вторых.
Мне попадались команды, где разработанные инструменты тут же становились общим достоянием. Макросы к редакторам, анализаторы логов, и даже форматировалки исходников. Все эти вещи разрабатывались совместно. И мне действительно трудно представить противоположную ситуацию. Почему человек вынужден делать для себя очевидный инструмент? Почему, сделав его, он не предлагает его команде? Ждёт, когда каждый сделает себе свой? Я действительно не понимаю логику такого поведения.

Shoonoise 22 апр 2014 в 17:45

К пробелам и деталям типа «типов в языках со слабой типизацией» либо не привязывались, .

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

либо проверяли линтерами и прочими инструментами

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

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

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

Вы выглядите приятным, разумным человеком, но в первом комментарии какую-то ерунду написали, честное слово.

maschingan 22 апр 2014 в 07:50

Недавно наткнулся на ESLint. Проект позиционирует себя как модульная альтернатива jslint/jshint, где каждый может легко добавлять свои правила. К сожалению пока руки не дошли попробовать, но было бы интересно сравнить и узнать мнение тех кто пользовался

bur 22 апр 2014 в 09:56

Уже много месяцев пользуюсь вашей разработкой в виде grunt-плагина grunt-jscs-checker во всех проектах. Ужасно доволен, спасибо вам огромное!
Не прочитал все коментарии, возможно уже спрашивали. Планируется ли сделать удобный интерфейс для генерации конфига jscs? Чтобы не читать весь ридми с последующей копипастой, а прощелкивать слайды, а в конце копировать конфиг?

mdevils 22 апр 2014 в 11:18

Нет, простого интерфейса для конфигурации нет. Но если вы разработаете, мы будем счастливы его принять и развивать.

bur 22 апр 2014 в 11:36

Ок, попробую набросать прототип на gh-pages в форке к вашему репу. Вопрос в том, будут ли его поддерживать, при добавлении новых правил, чтобы держать в актуальном состоянии…

mdevils 22 апр 2014 в 12:58

Если будет удобно и понятно реализовано, то пользователи смогут контрибьютить с учетом этой страницы.

bur 22 апр 2014 в 11:36

Мимо.

IonDen 23 апр 2014 в 08:58

youtrack.jetbrains.com/issue/WEB-10591
Поддержите предложение для JetBrains по внедрению этого плагина в их IDE.

Eternalko 1 окт 2014 в 20:52

Судя по камментам мало кто читал гитхаб и мало кто понял зачем данная итилита. Печально.

MaximAL 8 окт 2014 в 19:05

У нас в компании царят формат-фашизм и граммар-нацизм, поэтому JSCS наряду с JSHint стоит на хуках в репозиториях.
Нестильный код не пройдёт!

Спасибо за такую потрясающую утилиту.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий