コードの気候 - 複雑すぎるエラー

Question

私は自分のプロジェクトで気候気候を使用していますが、コードが "複雑すぎる"というエラーが表示されています。それほど複雑ではないコードを作る方法がわからないのですか？ここでは、次のとおりです。

方法：

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です。私の支店のすべてがこれに期待していますか？私は何をすべきか分からないのですか？どのように私はこれをより複雑にすることができます上の任意のアイデア？

Answer 1

コード・クライメートが何かが複雑すぎると思っても実際には分かりやすいとは思わないでしょう。コード気候は、コードをより読みやすく、簡単に書くのに役立ちます。しかし、それは厳しい規則を提供しません。

あなたが本当に何かを変更したい場合、あなたはそれが唯一の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で行うことができますが、この属性がどこから来ているのか、関連付けられているモデルであるのかは不明です。

Answer 2

クーポンサブハッシュをそのサブハッシュを返すメソッドとして抽出することができます。コードの複雑さが軽減されます（コーデックライメントの場合）が、実際には必要ありません。しかし、メソッドには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 

Answer 3

コードを使用して複雑な構造から別の構造にデータの変換を記述しようとしており、コードクライムのようなレビューツールの目には「複雑さ」がたくさんあります。役立つかもしれない

ことの一つは、データの面で変革を記述することである。

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? ] 
    } 
} 

これは巨大な変更のように見えるではないかもしれませんが、本当にそうではありませんが、それはいくつかの測定可能なメリットを提供しています。最初に、にを反映させることができます。コードを使用して設定を調べることができます。もう1つは、このフォーマットを定式化した後で、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 

たぶん、そのアプローチは、他の状況で役立ちますどこほとんど同じことをしています。

Answer 4

複雑さの警告を無視してください。

誤っています。

これらの警告は、偽の科学に基づいています。

サイクロマティックな複雑さは、1976年に学術雑誌で提案されており、実装が容易であるためツールビルダによって採用されてきました。

しかし、その元の研究には欠陥があります。

元の論文では、Fortranコードの複雑さを計算する簡単なアルゴリズムを提案していますが、計算された数値が実際にコードの読みやすさと理解可能性に相関しているという証拠は得られません。ナダ、ナンテ、ゼロ、ジルチェ。ここで

が彼らの抽象は

である。この論文では、グラフ理論の複雑さの指標について説明し、 は、プログラム 複雑さを管理し、制御するために使用する方法を示しています。この論文ではまず、グラフ理論の概念 がどのように適用され、 プログラミング用語のグラフの概念を直観的に説明するかについて説明します。いくつかの実際のFortran プログラムの制御グラフは、 の直感的な複雑さとグラフ理論的な複雑さとの間の相関関係を示すために提示される。例えば、 は、複雑さが物理的なサイズとは無関係であることを示す（すなわち、機能文の加算または減算は複雑さを残す）、複雑さは、 プログラムの決定構造にのみ依存するというグラフ理論的複雑性のいくつかの特性が証明される。

非構造化フローを使用する問題については、 も説明しています。構造化されていない制御グラフの特徴付けは で与えられ、プログラムの「構造化」を測定する方法は である。構造と還元性との間の関係は、いくつかの例で説明されている です。

は、複雑さの尺度 と関連して使用されるテスト方法を扱います。テスト戦略は プログラムは、どちらかが特定の最小限のテストレベルで認めることができますまたはあなただけの "与えられたanecdotical証拠を見ることができるように プログラムは構造的に

ソースhttp://www.literateprogramming.com/mccabe.pdf

を減少させることができることを指示するように定義されます直感的な複雑さとグラフ理論的な複雑さとの間の相関関係を説明するためのものであり、唯一の証拠は、このメトリックによって定義されるように、複雑度の低いコードを書き換えることができるということです。これは、複雑さのメトリックのための非常に非官能的な証明であり、その時からの研究の質にとって非常に共通しています。このペーパーは、今日の標準では公開できません。

この論文の著者は、ユーザーの研究を行っておらず、アルゴリズムは実際のいかなる証拠にも根拠がありません。それ以来、循環的複雑さとコード理解との間のリンクを証明することはできませんでした。この複雑さのメトリックは、現代の高水準言語ではなくFortranで提案されました。

コードの理解を保証する最善の方法はコードレビューです。他の人にあなたのコードを読んで理解していないものを修正するように頼んでください。

これらの警告をオフにするだけです。