Js-beautify: 支持逗号优先的变量声明方式

考虑到我们同时支持 JS 和 Python，补丁（严重过时）充其量是不完整的。

我们对拉取请求持开放态度，但我个人认为“逗号优先”是一种反模式。 从本质上讲，js-beautifier 对 JS 的外观有自己的看法，合理的选项在很大程度上符合广泛接受的“惯用”JS。 在我看来，逗号优先并不美观，也没有被广泛接受。 更重要的是，它会使美化代码（这已经非常复杂）变得非常复杂，而且收益很小。

设置了indent=4 ，哪种缩进合适？ 从一致性的角度来看，我认为：

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

这显然不是预期的输出。 使用制表符缩进看起来如何？

分号住在哪里？ 在末尾？ 无处？ （我都看过，还有更多）

这个要点同样过时，但更容易理解所需的更改： https :

这类似于#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 编辑器（逗号优先更普遍）的做法一致。

虽然我不提倡推广糟糕的布局，但我想在惯用和教条之间总是有一条细线（想想这里的克罗克福德）。 逗号优先可能并不普遍，因为许多格式化程序不支持它，无论他们的原因是什么。

您更熟悉代码方面的事务状态，因此我完全同意您的 ROI 论点。 尽管如此，我还是想问问，这样我们就可以将这些事情公开，有法定人数来讨论事情，如果社区有需求，也许你们可以重新考虑一下。

PS 我花了几个小时试图看看我是否可以快速剥离一些东西，但不是很成功。 也许我会在其他时候试一试。

@mrchief我很抱歉昨天的粗鲁，我正在从令人沮丧的调试会话中休息一下。 你提出了很好的观点，我想明确一点，我也尊重你的选择。 如果我提供补丁（逗号优先，无分号，其他古怪），我自己会尝试保持给定项目的风格，并且我确实同意这些选项至少可以帮助强制执行一点选择使用它们的项目的一致性。

+1。 我使用逗号优先模式，因为它在差异和合并时具有优势。

至于分号的位置：我换行了，与var关键字一致，像这样：

var a
  , b
  , c
;

我见过几个使用相同模式的项目。

另外，恕我直言，我认为能够将每个变量保留在单独的行中会很好，即使声明旁边没有给出值。 在上面的示例中，美化器将所有内容组合在一行var a, b, c; ，这也破坏了使用逗号拳头样式的整个目的。

+1 表示逗号优先支持。

在 2-space 缩进，这是排列变量的最整洁的方式：

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

每个标签有 4 个空格怎么样？ 实际标签？

2013 年 11 月 8 日星期五上午 9:36，Luke Martin通知@github.com
写道：

+1 表示逗号优先支持。
在 2 空格缩进，这是排列变量的最整洁的方式
var foo = 真
, bar = '你好'

， 某物;

直接回复此邮件或在 GitHub 上查看：
https://github.com/einars/js-beautify/issues/245#issuecomment -28081629

我想逗号优先问题的症结实际上归结为制表符偏好。

我使用 2 个空格的制表符，并且逗号之前是唯一一种在不添加不必要的空格的情况下排列变量的方法（~ 表示添加的额外空格以使事情对齐）：

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

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

相反，如果您使用 4 个空格的制表符，逗号前会看起来很糟糕，您自然不会关心对它的支持。

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

所以有关于逗号之前的讨论更容易评论和调试，等等。 但对我来说，这归结为美学。 我使用 2 个空格的制表符，所以我需要在前面使用逗号。 目前我不能使用 beautify 因为我更喜欢 2-space tabs。

现在我知道我可能是少数人，我绝对不会因为我的小偏爱而要求支持。 我只是将我的 +1 添加到对话中。 如果有时间，我什至可能会考虑自己添加支持。

干杯:)

我想为 json 对象看到这个。

变量 a = ({
 一：1
 ,乙：2
 });

@lukemartin这是一个有趣的观点！ ：+1：

逗号优先支持的另一个 +1，用于变量声明以及数组和对象 - https://gist.github.com/isaacs/357981

我一直在开发补丁以“按需”支持此功能（用户可以启用或禁用使用我创建的设置首先使用逗号的选项）。

我已经实现了以下变量声明格式（使用 2 个空格）：

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 抛出的 linting错误（缩进错误）。 例如：

myArray = [
    item1
  , item2
];

抛出“预期 ] 缩进 3，而不是 1”。 如果我们遵循建议，我们会得到一个非常难看的结果。

2.- 保持对齐每个属性名、数组项等开头的优点，例如：

myArray = [
  item1
  , item2
];

也不会产生 linting 错误，但看起来不像上面的例子那么好。

有了更清晰的想法，我应该如何处理这些情况，我就可以完成这个功能的实现并发出一个拉取请求。

是否可以支持以上所有内容？ 您列出的所有内容在技术上都是“逗号优先”。

我相信这是可能的，但有必要实施更多设置以允许用户实现所需的结果。 例如，有必要告诉格式化程序您是要对数组、对象和参数使用 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 代码中有一个 hack 来做很多标点优先的替代方案（对于三元运算符是必须的）。

对于所有对此 +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;

将是稍后讨论的调优示例。

听起来不错。 我很欣赏反馈。

非常感谢您查看它。 如果您有任何要添加的测试，那将是一个很大的帮助。