2017-12-14 18 views
0

私は急いでたくさんのコピー/ペーストを少しきれいに書いたコードを作ろうとしています。私は、同じことをすることに刺激的に近い2つの機能を持っていることに気づいた。elseブロックへのループの代替方法

def determine_risk(difference): 
    if difference > ON_TRACK: 
     return 'On Track' 
    elif difference < HIGH_RISK: 
     return 'High Risk' 
    else: 
     return 'Low Risk' 

def determine_completeness(pct_complete): 
    if pct_complete == UNSTARTED: 
     return 'Unstarted' 
    elif pct_complete > READY: 
     return 'Ready' 
    else: 
     return 'In Process' 

これを1つの機能に変えたいと思います。何かのように

def determine_condition(metric, [list_of_conditions], [list_of_outcomes], fallback) 
    for condition, outcome in zip(list_of_conditions, list_of_outomes): 
     if metric satisfies condition: 
       return outcome 
    return fallback 

問題は私はそういうリストに条件付きチェックを保存することはできないと思います!誰かが私に道を示し、またはあなたがラムダ式、例えばの配列としての条件を保存することができ1

+1

を行うので、あなたは(https://stackoverflow.com [このよう]意味/ questions/47728364/python-design-pattern-for-many-conditions)? – MrT

+0

あなたのコードを関数にラップし、それらの関数を使用してください... –

答えて

2

に機能のこれらの類似したタイプを組み合わせるための別のアプローチを見ていることができた場合にここに投稿:

a = lambda x: x > 1 
b = lambda x: x < 5 
conditions = [a, b] 

しかし、正直言って、私はしません。あなたの最初の例の2つの機能には間違いがありません - 彼らは分かりやすい名前を持っています。

2番目の例を使用するようにコードをリファクタリングした場合、これは失われます。私がdetermine_conditionへの呼び出しを見るときはいつも、関数が何をしているのかを読んで、束縛条件をチェックする一般的な方法であることを理解する必要があります。

可読性の祭壇で簡潔さを犠牲にする方がよい場合もあります。私にとっては、これはその時代の1つです。

編集

私が与えたラムダの例では、必要があると思い何であるブール値を返しませんでした - 修正彼らは

+0

ラムダ式を1行の 'def'ステートメントとして使用しないでください。 – chepner

+0

@chepnerこれは、彼がやろうとしていたことをOPがどのように達成するのかを実証するために考えることができる最も単純な例です。私の全体的なポイントは、私はあなたがこのようなことをするべきではないと思うということです:) –

+2

私はこれを素晴らしい答えと考えています。 「ここであなたがやろうとしていることをやり遂げる方法はありますが、ここではそのことをやってはいけない理由があります」とSO答えのパターンはかなり共通しています。 「これは動作しますが、しないでください」というコードのブロックを見直してください。 –

関連する問題