0

我在我的一个项目中使用了代码环境，但由于代码“太复杂”而出现错误。我不确定如何使它调用的代码不那么复杂？这里是：

方法：

 def apply_json
    {
      total_ticket_count: payment_details.tickets.count,
      subtotal: payment_details.subtotal.to_f,
      discount: payment_details.discount.to_f,
      fees: payment_details.fees_total.to_f,
      total: payment_details.total_in_dollars.to_f,
      coupon: {
        amount: payment_details.coupon.amount,
        type: payment_details.coupon.coupon_type,
        name: payment_details.coupon.name,
        valid: payment_details.coupon.valid_coupon?,
      }
    }
 end

它只是我藏在模型中的 JSON。我的分支上的一切都很好期待吗？我不知道该怎么办？关于如何使这不那么复杂的任何想法？

4

4 回答 4

3

如果 Code Climate 认为某些东西太复杂但实际上很容易理解，我不会太在意。Code Climate 应该可以帮助你编写更好、更易读的代码。但它没有提供硬性规则。

如果您真的想更改某些内容，您可能希望将coupon子哈希的生成移至Coupon模型，因为它仅取决于coupon关联提供的值：

def apply_json
  {
    total_ticket_count: payment_details.tickets.count,
    subtotal:           payment_details.subtotal.to_f,
    discount:           payment_details.discount.to_f,
    fees:               payment_details.fees_total.to_f,
    total:              payment_details.total_in_dollars.to_f,
    coupon:             payment_details.coupon.as_json
  }
end

# in coupon.rb
def as_json
  {
    amount: amount,
    type:   coupon_type,
    name:   name,
    valid:  valid_coupon?
  }
end

可以进行类似的重构，payment_details但不确定该属性来自何处以及它是否是关联模型。

于 2017-01-29T18:20:10.587 回答
3

请忽略复杂性警告。

他们被误导了。

这些警告是基于虚假科学。

圈复杂性已于 1976 年在学术期刊上提出，但由于易于实现而被工具制造商采用。

但最初的研究是有缺陷的。

原始论文提出了一种简单的算法来计算 Fortran 代码的复杂性，但没有提供任何证据表明计算出的数字实际上与代码的可读性和可理解性相关。纳达，niente，零，zilch。

这是他们的摘要

本文描述了一种图论复杂性度量，并说明了如何使用它来管理和控制程序复杂性。本文首先解释了图论概念是如何应用的，并在编程术语中对图概念进行了直观的解释。然后展示了几个实际 Fortran 程序的控制图，以说明直观复杂度和图论复杂度之间的相关性。然后证明了图论复杂性的几个属性，例如，复杂性与物理大小无关（添加或减去功能语句使复杂性保持不变）并且复杂性仅取决于程序的决策结构。

还讨论了使用非结构化控制流的问题。给出了非结构化控制图的特征，并开发了一种测量程序“结构化”的方法。结构和还原性之间的关系用几个例子来说明。

本文的最后一部分涉及与复杂性度量结合使用的测试方法；定义了一个测试策略，它规定程序可以接受某个最低测试级别，或者可以在结构上简化程序

来源http://www.literateprogramming.com/mccabe.pdf

正如您所看到的，仅给出轶事证据“以说明直观复杂性和图论复杂性之间的相关性”，唯一的证据是代码可以重写为具有该指标定义的较低复杂性数字。这对于复杂性指标来说是一个非常荒谬的证明，并且对于当时的研究质量来说非常普遍。按照今天的标准，这篇论文将无法发表。

该论文的作者没有做过用户研究，他们的算法没有任何实际证据为基础。从那以后，没有研究能够证明圈复杂度和代码理解之间的联系。更不用说这个复杂性度量是为 Fortran 而不是现代高级语言提出的。

确保代码理解的最佳方法是代码审查。只需让其他人阅读您的代码并修复他们不理解的内容即可。

因此，只需关闭这些警告。

于 2017-01-29T23:32:47.460 回答
1

您正在尝试使用代码描述数据从一种复杂结构到另一种结构的转换，这在 Code Climate 之类的审查工具眼中会产生很多“复杂性”。

可能有帮助的一件事是用数据来描述转换：

PAYMENT_DETAILS_PLAN = {
  total_ticket_count: [ :tickets, :count ],
  subtotal: [ :subtotal, :to_f ],
  discount: [ :discount, :to_f ],
  fees: [ :fees_total, :to_f ],
  total: [ :total_in_dollars, :to_f ],
  coupon: {
    amount: [ :coupon, :amount ],
    type: [ :coupon, :coupon_type ],
    name: [ :coupon, :name ],
    valid: [ :coupon, :valid_coupon? ]
  }
}

这似乎不是一个巨大的变化，实际上也不是，但它提供了一些可衡量的好处。首先是您可以对其进行反思，您可以使用代码检查配置。另一个是一旦你确定了这种格式，你就可以编写一个 DSL 来操作它，过滤或扩充它，等等。换句话说：它是灵活的。

解释这个“计划”并不难：

def distill(obj, plan)
  plan.map do |name, call|
    case (call)
    when Array
      [ name, call.reduce(obj) { |o, m| o.send(m) } ]
    when Hash
      [ name, distill(obj, plan) ]
    end
  end.to_h
end

当你把它付诸行动时，你会得到：

def apply_json
  distill(payment_details, PAYMENT_DETAILS_PLAN)
 end

也许这种方法在您做大部分相同事情的其他情况下会有所帮助。

于 2017-01-29T19:13:41.983 回答
0

您可以提取优惠券子哈希作为返回该子哈希的方法。它将降低代码复杂性（对于 codeclimate），但这并不是必需的。但是有些人认为该方法必须有 5 个字符串或更少。它们在大多数用例中都是正确的。但这完全由您决定。

def apply_json
  {
    total_ticket_count: payment_details.tickets.count,
    subtotal: payment_details.subtotal.to_f,
    discount: payment_details.discount.to_f,
    fees: payment_details.fees_total.to_f,
    total: payment_details.total_in_dollars.to_f,
    coupon: subhash
  }
 end

def subhash
  {
    amount: payment_details.coupon.amount,
    type: payment_details.coupon.coupon_type,
    name: payment_details.coupon.name,
    valid: payment_details.coupon.valid_coupon?,
  }
end
于 2017-01-29T18:19:09.000 回答