7

我刚刚开始使用 Ruby，并在 RubyMine 建议我更改此代码时发现了语句修饰符：

if !VALID_DIRECTIONS.include?(direction)
   raise ArgumentError, "Invalid direction"
end

对此：

raise ArgumentError, "Invalid direction" if !VALID_DIRECTIONS.include?(direction)

我喜欢它如何使代码更简洁。但是，乍一看，我可以看到它可能会产生误导，并且会造成可读性问题，因为它将效果放在条件之前。再说一次，也许这只是因为我太习惯 C 风格的语言了。

有没有人因为使用语句修饰符而遇到麻烦，或者你觉得他们改进了你的代码？此外，是否有人对使用修饰符有一般指导方针（即，对某些操作特别有效，或者对其他一些操作无效）？

4

4 回答 4

9

我发现如果仍然遵循其他代码可读性指南，我通常可以轻松阅读那些尾随条件（有时也称为它们） 。将一个 60 个字符的表达式和一个 40 个字符的条件放在同一行，你最终会得到一个 100 个字符的文本，这肯定是不可读的，完全独立于尾随条件的问题。

在您展示的特定代码示例中，很明显必须有一个条件跟随。谁不想raise先看ArgumentError一下论点？

此外，尾随条件类似于数学和函数语言中的保护子句，它们也倾向于写在它们保护的表达式之后。

最后但同样重要的是，在方法的开头放置几个raise Bar if foo和表达式，作为一种守卫，实际上被认为是一种很好的风格，以简化方法的控制流程。再说一遍：由于这些出现在方法的开头，很明显必须有一个条件，否则从方法的开头开始就没有意义。return nil if quuxreturn

PS：我实际上会在unless那里使用，以摆脱否定。对于更复杂的条件，我发现unless有时很难解析，但在这种情况下，它更明显，至少恕我直言。

于 2009-12-26T09:37:10.153 回答
8

语句修饰符使 ruby​​ 表现得更像英语，这很好：

  • 如果下雨，请待在家里
  • 如果下雨就呆在家里

我建议你使用对你来说最自然、最优雅的形式。如有疑问，请以两种形式大声朗读声明。就个人而言，我倾向于只对简短的陈述使用陈述修饰语，例如return :nope if input.nil?——对于更长或更复杂的陈述，读者可能需要更长的时间才能掌握，因为眼睛只覆盖一定的空间，所以有人只会阅读第二眼修饰符。

于 2009-12-26T08:13:37.170 回答
4

一开始对我来说有点奇怪，但我认为这不会造成可读性问题。当大量使用 Ruby 工作时，这非常有意义。只有当我与其他语言来回切换时，它才会引人注目。但是，当您沉浸在 Ruby 代码中时，您会发现它是一种编写单行条件语句的简洁明了的方式。另外，习惯使用unless. 您的代码行可以（也许应该）写成：

raise ArgumentError, "Invalid direction" unless VALID_DIRECTIONS.include?(direction)
于 2009-12-26T06:22:47.270 回答
0

这是一个纯粹主观的风格问题。使用任何你觉得舒服的东西。

于 2009-12-26T06:21:27.617 回答