一度だけ呼び出される1行関数

1行のコードを実行し、プログラムで1回だけ呼び出されるパラメーターレス（編集：必ずしもではない）関数を考えてください（将来再び必要になることは不可能ではありませんが）。

クエリを実行し、いくつかの値をチェックし、正規表現に関係する何かを実行できます。

この背後にある理論的根拠は、読みにくい評価を避けることです。

if (getCondition()) {
    // do stuff
}

where getCondition()は1行関数です。

私の質問は単純です：これは良い習慣ですか？私には大丈夫のようですが、長期については知りません...

その1行に依存します。行が読み取り可能で簡潔である場合、関数は必要ない場合があります。簡単な例：

void printNewLine() {
  System.out.println();
}

OTOH、複雑で読みにくい式などを含むコード行に関数が適切な名前を付けた場合、それは完全に正当化されます（私にとって）。工夫された例（ここでは読みやすくするために複数の行に分けています）：

boolean isTaxPayerEligibleForTaxRefund() {
  return taxPayer.isFemale() 
        && (taxPayer.getNumberOfChildren() > 2 
        || (taxPayer.getAge() > 50 && taxPayer.getEmployer().isNonProfit()));
}

はい、これはベストプラクティスを満たすために使用できます。たとえば、1行の長さであっても、より大きな関数内でそのコード行を使用し、その機能を説明する1行のコメントを必要とするよりも、明確に名前が付けられた関数に何らかの作業をさせる方が良いです。また、隣接するコード行は、同じ抽象化レベルでタスクを実行する必要があります。反例は次のようになります

startIgnition();
petrolFlag |= 0x006A;
engageChoke();

この場合、中央の行を適切な名前の関数に移動することをお勧めします。

多くの場合、そのような関数は良いスタイルだと思いますが、他の場所のどこかでこの条件を使用する必要がない場合、ローカルのブール変数を代替と考えることができます。

bool someConditionSatisfied = [complex expression];

これにより、コードリーダーにヒントが提供され、新しい関数の導入が不要になります。

Peterの答えに加えて、その条件を将来のある時点で更新する必要がある場合、単一の編集ポイントのみを持つように提案する方法でカプセル化することにより、

ピーターの例に従って、これが

boolean isTaxPayerEligibleForTaxRefund() {
  return taxPayer.isFemale() 
        && (taxPayer.getNumberOfChildren() > 2 
        || (taxPayer.getAge() > 50 && taxPayer.getEmployer().isNonProfit()));
}

これになります

boolean isTaxPayerEligibleForTaxRefund() {
  return taxPayer.isMutant() 
        && (taxPayer.getNumberOfThumbs() > 2 
        || (taxPayer.getAge() > 123 && taxPayer.getEmployer().isXMan()));
}

単一の編集を行うだけで、全体的に更新されます。保守性に関しては、これはプラスです。

パフォーマンスに関しては、ほとんどの最適化コンパイラは関数呼び出しを削除し、とにかく小さなコードブロックをインライン化します。このようなものを最適化すると、実際にブロックサイズが縮小される可能性があり（関数呼び出し、リターンなどに必要な命令を削除することにより）、通常はインライン化を妨げる可能性がある条件でも安全に実行できます。

読みやすさに加えて（またはそれを補完して）、適切な抽象化レベルで関数を記述することができます。

場合によります。式が1行だけであっても、関数/メソッドに式をカプセル化した方が良い場合があります。読むのが複雑な場合、または複数の場所で必要な場合は、それをお勧めします。長期的には、単一の変更点と読みやすさを導入したため、メンテナンスが容易です。

ただし、必要のない場合もあります。式がとにかく読みやすい、および/または一箇所に表示される場合は、それをラップしないでください。

あなたがそれらのいくつかを持っているなら、それは大丈夫ですが、あなたのコードにそれらがたくさんあるときに問題が発生すると思います。そして、コンパイラーが実行されるか、インターピター（使用する言語に応じて）が実行されると、メモリー内のその関数になります。コンピューターが気付かないとは思わないが、そのうちの3つを持っていると言うことができますが、それらの小さなものが100を数え始めると、システムは一度だけ呼び出されてから破棄されない関数をメモリに登録する必要があります。

コメントを除いてコードの実際の意味を明確にするために、リファクタリングしているアプリケーションでこの正確なことを最近行いました。

protected void PaymentButton_Click(object sender, EventArgs e)
    Func<bool> HaveError = () => lblCreditCardError.Text == string.Empty && lblDisclaimer.Text == string.Empty;

    CheckInputs();

    if(HaveError())
        return;

    ...
}

その1行を適切な名前のメソッドに移動すると、コードが読みやすくなります。他の多くの人がすでにそれについて言及しています（「自己文書化コード」）。メソッドに移動することのもう1つの利点は、単体テストが容易になることです。独自のメソッドに分離され、単体テストが行​​われた場合、バグが見つかった場合、バグがこのメソッドに含まれないことを確認できます。

すでに多くの良い答えがありますが、言及する価値のある特別なケースがあります。

1行のステートメントにコメントが必要で、その目的を明確に識別できる（つまり、名前を付けることができる）場合は、コメントをAPIドキュメントに拡張しながら関数を抽出することを検討してください。このようにして、関数呼び出しをより速く、より簡単に理解できるようにします。

興味深いことに、現在何もしない場合でも同じことができますが、必要な拡張を思い出させるコメント（非常に近い将来^1））

def sophisticatedHello():
    # todo set up
    say("hello")
    # todo tear down

これに変更することもできます

def sophisticatedHello():
    setUp()
    say("hello")
    tearDown()

^1）あなたはこれについて本当に確信しているべきです（YAGNIの原則を参照）

言語でサポートされている場合、通常はラベル付き匿名関数を使用してこれを実現します。

someCondition = lambda p: True if [complicated expression involving p] else False
#I explicitly write the function with a ternary to make it clear this is a a predicate
if (someCondition(p)):
    #do stuff...

私見これは、複雑な式がif条件を乱雑にしない一方で、小さなスローアウェイラベルでグローバル/パッケージの名前空間を乱雑にしないことの読みやすさの利点を与えるので、良い妥協です。関数 "definition"が使用されている場所で適切であり、定義の変更と読み取りが容易になるという利点もあります。

述語関数である必要はありません。私はこのような小さな関数にも繰り返しボイラープレートを入れるのが好きです（ブラケット構文を乱雑にすることなくpythonリストの生成に特にうまく機能します）。たとえば、PythonでPILを使用する場合の次の簡単な例

#goal - I have a list of PIL Image objects and I want them all as grayscale (uint8) numpy arrays
im_2_arr = lambda im: array(im.convert('L')) 
arr_list = [im_2_arr(image) for image in image_list]