Js-beautify: Поддержка первого стиля объявления переменных через запятую

Учитывая, что мы поддерживаем как JS, так и Python, патч (который сильно устарел) в лучшем случае неполный.

Мы открыты для запросов на вытягивание, но я лично считаю, что «сначала запятая» является анти-шаблоном. По своей сути js-beautifier придерживается мнения о том, как должен выглядеть JS, с разумными вариантами, которые в значительной степени соответствуют широко принятому «идиоматическому» JS. На мой взгляд, первая запятая некрасива и не получила широкого распространения. Более того, это сильно усложнит код украшения (который и без того невероятно сложен) с очень небольшим выигрышем.

Какой отступ подходит для набора indent=4 ? С точки зрения согласованности я бы сказал следующее:

var a = 1
    , b = "foo"
    , c = false;

Что явно не является ожидаемым результатом. И как это будет выглядеть с отступами табуляции?

Где живет точка с запятой? В конце? Никуда? (Я видел и то, и другое)

Эта суть так же устарела, но упрощает понимание желаемого изменения: https://gist.github.com/nemtsov/2864266/revisions

Это похоже на # 80, поэтому я подумал, что причины могут быть те же - более легкое различие и изменение порядка.

Но в этом сценарии, в отличие от # 80, есть жизнеспособный обходной путь, который удовлетворяет этим требованиям:

var a = 1;
var b = "foo";
var c = false;

Это немного более многословно, но не ужасающе.

Конечно, если кто-то реализует # 80, самое простое изменение, вероятно, коснется и этого сценария.
Как сказал @evocateur ,

@evocateur : Вы имеете право на свое мнение, и я его уважаю. Лично мне всегда не нравился стиль с запятой, но на протяжении многих лет я ценил легкость перемещения, удаления (комментирование, удаление и т. Д.) И, как говорит @bitwiseman, -

@bitwiseman : На любом уровне отступа (2 или 4) я думаю, это должно выглядеть так:

var a = 1
  , b = "foo"
  , c = false;

Я думаю, что это также согласуется с тем, как это делают некоторые редакторы SQL (где сначала запятая используется чаще).

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

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

PS Я потратил пару часов, пытаясь понять, смогу ли я быстро что-то выдать, и у меня не получилось. Может быть, я попробую как-нибудь в другой раз.

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

+1. Я использую шаблон «сначала запятая», потому что он дает преимущества при различении и слиянии.

Что касается положения точки с запятой: я помещаю ее в новую строку в соответствии с ключевым словом var , например:

var a
  , b
  , c
;

Я видел несколько проектов, в которых используется один и тот же шаблон.

Кроме того, IMHO, я думаю, было бы неплохо иметь возможность хранить каждую переменную в отдельной строке, даже если значение не указано рядом с объявлением. В приведенном выше примере украситель сгруппировал бы все в одну строку var a, b, c; что также нарушает всю цель использования стиля запятая кулак.

+1 за поддержку ввода запятых.

С отступом в 2 пробела это самый удобный способ расстановки переменных:

var foo = true
  , bar = 'hello'
  , something;

А как насчет 4 пробелов на вкладку? Актуальные вкладки?

Пт, 8 ноября 2013 г., в 9:36, Люк Мартин [email protected]
написал:

+1 за поддержку ввода запятых.
С отступом в 2 пробела это самый удобный способ расстановки переменных.
var foo = true
, bar = 'привет'

, что-то;

Ответьте на это письмо напрямую или просмотрите его на GitHub:
https://github.com/einars/js-beautify/issues/245#issuecomment -28081629

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

Я использую табуляции с двумя пробелами, и запятая перед ними - единственный способ упорядочить переменные без добавления ненужных пробелов (~ представляют дополнительные пробелы, добавленные, чтобы выровнять вещи):

// eww
var foo = true,
  ~~bar = 'hello',
  ~~something;

// yum
var foo = true
  , bar = 'hello'
  , something;

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

// also eww
var foo = true
    , bar = 'hello'
    , something;

Итак, обсуждается запятая, прежде чем ее будет легче комментировать, отлаживать и бла-бла-бла. Но для меня все сводится к эстетике. Я использую табуляцию с двумя пробелами, поэтому мне нужно использовать запятую перед. В настоящее время я не могу использовать beautify, потому что предпочитаю вкладки с двумя пробелами.

Теперь я знаю, что, вероятно, в меньшинстве, и я абсолютно не требую поддержки из-за моего небольшого предпочтения. Я просто добавлял +1 к разговору. Я мог бы даже подумать о добавлении поддержки, если у меня будет время.

Ваше здоровье :)

Я бы хотел увидеть это для объектов json.

 var a = ({
 а: 1
 ,Би 2
 });

@lukemartin Это интересная перспектива! : +1:

Еще один +1 для поддержки первой запятой, для объявления переменных, а также массивов и объектов - https://gist.github.com/isaacs/357981

Я работал над патчем для поддержки этой функции «по запросу» (пользователь может включить или отключить возможность использования запятой вначале с настройкой, которую я создал).

Я добился следующего форматирования объявления переменных (с использованием двух пробелов):

var firstVar = 1
  , secondVar = 2
  , thirdVar = 3
;

Но у меня есть сомнения.

Как следует относиться к объявлениям массивов, объектов и аргументов? В последнее время я использую следующий формат:

myArray = [
  item1
, item2
, item3
];

myObject = {
  prop1: 1
, prop2: 2
, prop3: 3
}

Что, как вы можете видеть, не совсем то же самое, что форматирование объявления переменной: последний включает уровень отступа +1 для второй переменной (обратите внимание на два пробела перед запятой, которых нет перед запятой для "item2" ни для "prop2"). Объявления Var используют этот дополнительный отступ, чтобы выровнять в одном столбце начало каждого имени переменной, как указано @lukemartin.

Причины использования форматирования, показанного в приведенном выше коде:

1.- Чтобы избежать ошибок линтинга, которые могут быть вызваны jshint (ошибки отступа). Например:

myArray = [
    item1
  , item2
];

Выбрасывает «Ожидается] иметь отступ на 3, а не на 1». Если мы последуем предложению, мы получим очень некрасивый результат.

2.- Чтобы сохранить преимущество выравнивания начала каждого имени свойства, элемента массива и т. Д. Например:

myArray = [
  item1
  , item2
];

Также не вызывает ошибок линтинга, но выглядит не так хорошо, как в приведенных выше примерах.

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

Можно ли поддержать все вышеперечисленное? Технически все, что вы указали, ставится «сначала запятая».

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

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

Как вы говорите, базовая функциональность в порядке. Поддерживать _все_ параметры форматирования _не цели_ этого проекта. :улыбка:

// 2-space indents
var itemA = 1
  , itemB: 2
  , itemC: 3;

myObj = {
  itemA: 1
  , itemB: 2
}

myArray = [
  item1
  , item2
];

// 4-space indents
var itemA = 1
    , itemB: 2
    , itemC: 3;

myObj = {
    itemA: 1
    , itemB: 2
}

myArray = [
    item1
    , item2
];

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

Я с нетерпением жду вашего запроса на перенос!

@tgirardi Отличная работа. Не могу дождаться, чтобы попробовать это.

Все отзывы приветствуются :-) !!!

Моя идея состоит в том, чтобы скорректировать код до тех пор, пока он не будет считаться правильным решением, а затем перейти к следующему списку TODO:

1.- Создайте тесты для этой новой функции
2.- Применить функцию к версии Python (если кто-то захочет это сделать, даже лучше! ... У меня нет большого опыта работы с python).
3.- Обсудите другие возможные варианты стилей, начинающихся с запятой.

Отступ из 4 пробелов

var x = a
    , y = b
;
obj = {
    attr1: "value1"
    , attr2: "value2"
    , attr3: "value3"
};

Имена переменных и имена атрибутов не должны быть выровнены. Это никак не влияет на читабельность. На мой взгляд, основная причина использования функции column-first - упростить комментирование, удаление и вставку строк. Это просто происходит при использовании отступа в 2 пробела.

Полустолбец должен быть на отдельной строке после объявления нескольких переменных, чтобы было легче добавить новую переменную после «y». В этом случае в VIM, 'o' + ', z = c' вместо '$ a,'+' z = c '

@lewisdiamond Я согласен с вашим комментарием с запятой . Наличие его в собственной строке гарантирует, что последняя переменная также может быть легко отредактирована (удалить, заменить, вставить строку после / до и т. Д.).

Но также было отмечено, что:

1.- Поддерживать все виды форматирования не является целью проекта.
2.- Слишком много сложностей сразу - плохая идея. Поэтому было бы лучше сначала сохранить эту функцию как можно более простой и начать улучшать ее после того, как она достигнет состояния выпуска и будет протестирована в течение некоторого времени.

+1 за поддержку сначала запятых, и я согласен с мнением lewisdiamond, что обеспечение правильного выравнивания вкладок не должно быть конечной целью, поскольку есть прагматические причины для стиля, начинающегося с запятой. Я также хотел бы получить поддержку json. В настоящее время у меня есть хак в глобальном коде js-beautify, чтобы сделать множество альтернатив с первым знаком пунктуации (для тернарных операторов было необходимо).

Всем, кто поставил +1: посмотрите ветку https://github.com/beautify-web/js-beautify/tree/feature/comma-first .

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

@olsonpm , @lewisdiamond , @lukemartin , @mrchief - не могли бы вы взглянуть на ветку https://github.com/beautify-web/js-beautify/tree/feature/comma-first .

Я потрачу на это сегодня 30 минут и отвечу мыслями. Спасибо за продолжение.

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

Когда я создавал свою личную ветку, я решил, что оператор, начинающийся с запятой, будет пассивным, что означает следующее:

var a,
    b;

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

Еще одна вещь, <Output> .previous_line и flags.previous_text - это то же самое, что я считаю, что сначала сбивало меня с толку, но имело смысл в том, как вы их использовали.

Помимо этого, основное различие между нашими реализациями заключается в том, что вы решили изменить предыдущую строку. Я старался не «возвращаться и редактировать вещи», потому что думал, что разработка будет более запутанной. Теперь ваш способ более лаконичный, чем мой - он легко читается и вы все комментировали. Существующий код также редактирует предыдущие токены, поэтому ваш код полностью соответствует - честно говоря, я просто говорю об этом, потому что хотел бы знать, что вы думаете. Короче говоря, я считаю, что эту программу было бы намного проще отлаживать, если бы токены отвечали только за пустое пространство перед ними на основе следующих токенов.

Спасибо, что обратились к этому!

Изменить: Моя ошибка - <Output> .previous_line и flags.previous_text совершенно разные.

Только вперед предпочтительнее. Я посмотрел на комок того, как и где мы решаем, что делать с запятыми / насчет запятых, уже есть места, где мы обрезаем вывод, чтобы получить их в нужном месте. Я решил сделать что-то немного упрощенное, пройти несколько тестов, чтобы проверить упрощенное поведение, а затем подумать о настройке и рефакторинге позже.

Пример, который вы упомянули:

var a,
    b;

Это был бы пример настройки, о которой можно было бы поговорить позже.

Звучит отлично. Я ценю обратную связь.

И большое спасибо за просмотр. Если у вас есть какие-либо тесты, которые вы хотите добавить, это будет большим подспорьем.