ABC大小太高，即使没有分支，分配或条件

“为拉伸分配分支条件大小过高[一十五分之二十九]。”

为下述方法：

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 
    ...

因为有没有分配，分支，在这里也没有条件！

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

来源

2017-04-01 flajann

我不完全了解ABC（作业/分支/条件）的工作原理，但您可以从[wikipedia]（https://en.wikipedia.org/wiki/ABC_score）页面看到函数调用通常会被处理作为分支。 [这里]（https://github.com/bbatsov/rubocop/blob/master/lib/rubocop/cop/metrics/abc_size.rb）是决定这个分数的rubocop来源，[here]（https：// github.com/bbatsov/rubocop/blob/master/config/default.yml）是rubocop默认值（默认的最大ABC分数是15）。 –

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

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

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

我们可以检查，这是正确的通过计数所述消息发送的方法，包括：

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

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

什么是坏对这个功能呢？要改变它似乎很愚蠢，我不清楚它会带来什么“好处”。

不要犯RuboCop万能的错误。它既不读取也不理解代码。它没有“更好”代码的概念。它应用了一些（相当原始的）启发式方法，它为我们提供了一个“质量”的替代指标。我们需要解释并决定采取什么行动。

RuboCop挣扎的一种常见情况是声明式DSL。在这些情况下，通常最好禁用那些破坏的警察。 RuboCop提供不同级别的粒度来完成此操作。您可以使用rubocop:disable CopName（请记住重新启用它），在文件或目录的基础上，使用.rubocop.yml或同一文件中的整个项目进行内联。

来源

2017-04-02 03:31:47 Drenmi

谢谢你的回答。我正在研究一个项目，Rubocop已经成为构建过程的一部分。也就是说，如果Rubocop不开心，它会失败。为了完成工作，我可能会禁用Rubocop！再次感谢。 – flajann

@ flajann：不客气！您可以在这里找到有关不同配置选项的更多信息：http://rubocop.readthedocs.io/en/latest/configuration/ – Drenmi

ABC大小太高，即使没有分支，分配或条件

回答

相关问题