ABC 大小太高，即使没有分支、赋值或条件

Question

我对 RuboCop 抱怨的内容感到困惑。

“抽奖的分配分支条件大小太高。[29/15]”

以下方法：

class Ball
  attr_reader :color
  attr_reader :center
  attr_reader :radius
  attr_reader :dir
  attr_reader :x, :y
  attr_reader :w, :h
  attr_accessor :worldWidth
  attr_accessor :worldHeight
  ...
  # Draw the ball into this device context
  def draw(dc)
    dc.setForeground(color)
    dc.fillArc(x, y, w, h, 0, 64 * 90)
    dc.fillArc(x, y, w, h, 64 * 90, 64 * 180)
    dc.fillArc(x, y, w, h, 64 * 180, 64 * 270)
    dc.fillArc(x, y, w, h, 64 * 270, 64 * 360)
  end
  ...

因为这里没有赋值、分支和条件语句！

我错过了什么？无论如何，这个功能有什么不好？不得不改变它似乎很愚蠢，我不清楚它会带来什么“好处”。请澄清！

Answer 1

RuboCop 用来计算 ABC 大小的公式是：

sqrt(assignments^2 + branches^2 + condition^2)

消息发送（也称为方法调用）在 RuboCop 中被视为一个“分支”。正如您所指出的，因为在这种情况下没有分配或条件，所以此方法的 ABC 大小由 sqrt(branches^2) 或简单地说 branches 给出。

我们可以通过计算方法中发送的消息来检查这是否正确：

• 1 x #setForeground
• 1 x #color
• 4 x #fillArc
• 4 x #x
• 4 x #y
• 4 x #w
• 4 x #h
• 7 x #*

总计 29，这是我们预期的 ABC 大小。

---

这个函数到底有什么不好呢？不得不改变它似乎很愚蠢，我不清楚它会带来什么“好处”。

不要误以为 RuboCop 是无所不能的。它既不阅读也不理解代码。它没有“更好”代码的概念。它应用了一些（相当原始的）启发式方法，为我们提供了“质量”的代理衡量标准。由我们来解释并决定采取什么行动。

RuboCop 遇到困难的一个常见情况是声明性 DSL。在这些情况下，通常最好禁用崩溃的警察。 RuboCop 提供了不同级别的粒度来执行此操作。您可以使用rubocop:disable CopName（记得再次启用它）、.rubocop.yml 中的文件或目录或同一文件中的整个项目进行内联操作。