Coffeescript在1.1.1和1.3.3版本之间呈现不同。

Question

CoffeeScript源代码

return sprite: myFunc
  width: 79
  height: 66
throw:
  from: {}
  last: {}

使用CoffeeScript 1.1.1编译

return {
  sprite: myFunc({
    width: 79,
    height: 66
  }),
  "throw": {
    from: {},
    last: {}
  }
};

使用CoffeeScript 1.3.3编译

return {
  sprite: myFunc({
    width: 79,
    height: 66
  })
};

({
  "throw": {
    from: {},
    last: {}
  }
});

这破坏了我的代码。在版本之间的更改日志中我看不到任何东西。这是一个错误吗？

- Billy Moon

Answer 1

我会称之为一个bug，但是这个bug是在1.1.1版本中，并且存在于你的代码中依赖于特定解释模糊代码的部分。具体来说：

return sprite: myFunc
  width: 79
  height: 66
throw:
  from: {}
  last: {}

在块throw应该位于哪里可能有点模糊，但我认为1.3.3的解释是唯一有意义的：您的缩进与您的意图不匹配。

如果我们添加一个函数包装器以增加清晰度：

f = ->
  return sprite: myFunc
    width: 79
    height: 66
  throw:
    from: {}
    last: {}

那么，任何模棱两可的地方都消失了，1.3.3解释如下：

f = ->
  return { sprite: myFunc(width: 79, height: 66) }
  { throw: { from: {}, last: {} } }

这句话很好理解，因为你的结构只是一个变体：

f = ->
  return pancakes
  eggs

即使括号和圆括号等是可选的，也不意味着它们被禁止使用。如果一段代码结构的意图不能一眼看出，那么您应该使用一些括号和圆括号来强制结构，例如：

return { sprite: myFunc
  width: 79
  height: 66
throw:
  from: {}
  last: {}
}

或者更好（在我看来）：

return {
  sprite: myFunc(
    width: 79
    height: 66
  )
  throw:
    from: {}
    last: {}
}

很不幸，您需要阅读所有的 CoffeeScript 代码，并根据需要添加大括号。我希望您有非常好的测试套件。

---

有趣的是，如果删除 return：

sprite: myFunc
  width: 79
  height: 66
throw:
  from: {}
  last: {}

那么你将得到最新的解释：

{
  sprite: myFunc(...)
  throw:  { from: ... }
}

对我来说这非常有意义，因为它看起来像：

v =
  sprite: myFunc ...
  throw: ...

明确使用return会引入上下文，而在暗示情况下不存在上下文。

- mu is too short

---

这是一个非常详尽的答案，特别是因为您注意到了return引入时上下文的变化。我认为在coffeescript中空格没有被充分考虑，添加括号对我来说似乎不是正确的答案，因为coffeescript易读性和编辑便捷性的关键之一就是不必匹配括号。 - Billy Moon

@BillyMoon：我对无括号和可读性之间的关联持不同意见，尤其是在（Coffee|Java）Script代码中使用回调等嵌套较多的情况下。我倾向于大量使用大括号和圆括号，以便一目了然地理解代码结构；我还经常使用单次使用的方法，只是为了避免过多嵌套带来的视觉混乱。但我们都不是八岁的孩子，所以我们可以放下这场争论 :) - mu is too short

更大的问题是，如果我现在编写了在CoffeeScript中运行的代码，但如果我更新了CoffeeScript版本，它可能就无法正常工作 - 这对我来说是一个关键问题。 - Billy Moon

我了解你所说的问题，以及它与“空格没有被充分考虑”的关系。CoffeeScript 没有正式的规范委员会，因此我们必须在实践中发现这些问题，而不是通过 10 年的委员会肉磨机。理想情况下，CoffeeScript 编译器应该有一个“lint”模式，可以抱怨模棱两可的结构。如果一种语言/库/... 倾向于向后兼容性，你最终会得到一个大混乱；如果它不这样做，你最终会得到另一种类型的大混乱。 - mu is too short

@BillyMoon：我希望我能对此有更好的评价。最前沿技术往往伴随着一些痛苦和折磨。 - mu is too short