ブロック内の追加行とクリーンコード内の追加パラメーター

コンテキスト

できれいなコード、35ページ、それは言います

これは、ifステートメント、elseステートメント、whileステートメントなど内のブロックが1行の長さであることを意味します。おそらくその行は関数呼び出しであるべきです。これにより、囲んでいる関数が小さく保たれるだけでなく、ブロック内で呼び出される関数にわかりやすい名前を付けることができるため、ドキュメントの価値も高まります。

私は完全に同意します、それはとても理にかなっています。

後で40ページで、関数の引数について説明します

関数の理想的な引数の数はゼロ（niladic）です。次に1つ（単項）、2つ（2項）が続きます。可能な場合は、3つの引数（3項）を避ける必要があります。3つ以上（ポリアディック）には非常に特別な正当化が必要です。引数は難しいです。彼らは多くの概念的な力を取ります。

私は完全に同意します、それはとても理にかなっています。

問題

しかし、しばしば私は別のリストからリストを作成していることに気づき、2つの悪の1つと一緒に暮らさなければなりません。

ブロック内で2つの行を使用します。1つは物を作成するため、もう1つは結果に追加するためです。

    public List<Flurp> CreateFlurps(List<BadaBoom> badaBooms)
    {
        List<Flurp> flurps = new List<Flurp>();
        foreach (BadaBoom badaBoom in badaBooms)
        {
            Flurp flurp = CreateFlurp(badaBoom);
            flurps.Add(flurp);
        }
        return flurps;
    }

または、事物が追加されるリストの関数に引数を追加し、「1つの引数が悪化する」ようにします。

    public List<Flurp> CreateFlurps(List<BadaBoom> badaBooms)
    {
        List<Flurp> flurps = new List<Flurp>();
        foreach (BadaBoom badaBoom in badaBooms)
        {
            CreateFlurpInList(badaBoom, flurps);
        }
        return flurps;
    }

質問

私が見ていない（不利な）利点はありますか？または、特定の状況でそのような利点があります。その場合、決定を下すときに何を探すべきですか？

これらのガイドラインは地図ではなくコンパスです。彼らはあなたを賢明な方向に向けます。しかし、どのソリューションが「最良」であるかを絶対的な言葉で説明することはできません。ある時点で、目的地に到着したため、コンパスが指している方向への歩行を停止する必要があります。

Clean Codeは、コードを非常に小さな明白なブロックに分割することをお勧めします。それは一般的に良い方向です。しかし（引用されたアドバイスの文字通りの解釈が示唆するように）極端に取られたとき、あなたはあなたのコードを無駄な小さな断片に細分化するでしょう。実際には何もしません。すべてが委任されます。これは、本質的に別の種類のコード難読化です。

「小さければ小さいほど良い」と「小さすぎるなら役に立たない」のバランスを取ることがあなたの仕事です。どのソリューションがより簡単かを自問してください。私にとって、それは明らかにリストを組み立てるため、明らかに最初のソリューションです。これはよく知られているイディオムです。さらに別の関数を見なくても、そのコードを理解できます。

もっとうまくやれるなら、「すべての要素をリストから別のリストに変換する」ことが一般的なパターンであり、機能的なmap()操作を使用して抽象化できることが多いことに注意してください。C＃では、と呼ばれると思いますSelect。このようなもの：

public List<Flurp> CreateFlurps(List<BadaBoom> badaBooms)
{
    return badaBooms.Select(BadaBoom => CreateFlurp(badaBoom)).ToList();
}

関数の理想的な引数の数はゼロ（niladic）です

いや！関数の理想的な引数の数は1です。ゼロの場合、アクションを実行するために関数が外部情報にアクセスする必要があることを保証しています。「おじ」ボブはこれを非常に間違っていました。

コードに関しては、最初の行にローカル変数を作成しているため、最初の例のブロックには2行しかありません。その割り当てを削除すると、次のクリーンコードガイドラインに準拠しています。

public List<Flurp> CreateFlurps(List<BadaBoom> badaBooms)
{
    List<Flurp> flurps = new List<Flurp>();
    foreach (BadaBoom badaBoom in badaBooms)
    {
        flurps.Add(CreateFlurp(badaBoom));
    }
    return flurps;
}

しかし、それは非常に長い（C＃）コードです。次のようにしてください：

IEnumerable<Flurp> CreateFlurps(IEnumerable<BadaBoom> badaBooms) =>
    from badaBoom in babaBooms select CreateFlurp(badaBoom);

「クリーンコード」アドバイスは完全に間違っています。

ループで2行以上を使用します。関数内で同じ2行を非表示にするのは、説明が必要なランダムな数学の場合に意味がありますが、行がすでに記述的である場合は何もしません。「作成」および「追加」

2行目を避けるために2番目の引数を追加する必要はないため、2番目の方法は実際には意味がありません。

public List<Flurp> CreateFlurps(List<BadaBoom> badaBooms)
    {
        List<Flurp> flurps = new List<Flurp>();
        foreach (BadaBoom badaBoom in badaBooms)
        {
            flurps.Add(badaBoom .CreateFlurp());
            //or
            badaBoom.AddToListAsFlurp(flurps);
            //or
            flurps.Add(new Flurp(badaBoom));
            //or
            //make flurps a member of the class
            //use linq.Select()
            //etc
        }
        return flurps;
    }

または

foreach(var flurp in ConvertToFlurps(badaBooms))...

他の人が指摘しているように、最良の関数は引数のない関数であるというアドバイスは、せいぜいOOPに偏っており、最悪の場合には単純な悪いアドバイスです。

CreateFlurpInListリストを受け入れ、そのリストを変更し、関数を純粋でなく推論するのが難しくなるため、2番目は間違いなく悪いです。メソッド名に、メソッドがリストに追加するだけであることを示唆するものはありません。

そして、私は3番目の、最高のオプションを提供します：

public List<Flurp> CreateFlurps(List<BadaBoom> badaBooms)
{
    return badaBooms.Select(CreateFlurp).ToList();
}

地獄、それが使用される場所が1つしかない場合、そのメソッドはすぐにインライン化できます。1ライナーはそれ自体で明確であるため、意味を与えるためにメソッドでカプセル化する必要はありません。

引数が1つのバージョンの方が優れていますが、主に引数の数が原因ではありません。

それが優れている最も重要な理由は、カップリングが低いことです。これにより、より便利で、推論が容易になり、テストが容易になり、コピー+貼り付けられたクローンになりにくくなります。

あなたが私を提供した場合はCreateFlurp(BadaBoom)シンプル：、私は、回収容器のいずれかのタイプのものを使用することができFlurp[]、List<Flurp>、LinkedList<Flurp>、Dictionary<Key, Flurp>、など。しかし、CreateFlurpInList(BadaBoom, List<Flurp>)をCreateFlurpInBindingList(BadaBoom, BindingList<Flurp>)使用して、リストが変更されたという通知を私のビューモデルが取得できるように、明日あなたに戻ってきます。うん！

追加の利点として、より単純な署名が既存のAPIに適合する可能性が高くなります。あなたは繰り返し問題があると言います

かなり頻繁に、私は自分が別のリストからリストを作成していることに気付く

使用可能なツールを使用するだけです。最も短く、最も効率的で、最高のバージョンは次のとおりです。

var Flurps = badaBooms.ConvertAll(CreateFlurp);

これにより、コードの記述とテストが減るだけでなくList<T>.ConvertAll()、結果が入力と同じ数のアイテムを持つことを認識し、結果リストを正しいサイズに事前に割り当てることができるため、高速です。コード（両方のバージョン）でリストを増やす必要がありました。

全体的な目標を念頭に置いてください：コードを読みやすく、保守しやすくします。

多くの場合、複数の行を単一の意味のある関数にグループ化できます。これらの場合にそうしてください。場合によっては、一般的なアプローチを再検討する必要があります。

たとえば、あなたの場合、実装全体をvarに置き換えます

flups = badaBooms.Select(bb => new Flurp(bb));

可能性があります。または、あなたは次のようなことをするかもしれません

flups.Add(new Flurp(badaBoom))

場合によっては、最もクリーンで読みやすいソリューションが1行に収まらないことがあります。したがって、2行になります。何らかのarbitrary意的なルールを満たすためだけに、コードを理解しにくくすることはしないでください。

2番目の例は（私の意見では）最初の例よりも理解するのがかなり難しいです。2番目のパラメーターがあるだけでなく、パラメーターが関数によって変更されるということです。Clean Codeがそれについて言っていることを調べてください。（現在、本を手元に持っていませんが、基本的には「避けることができるなら、それをしないでください」と確信しています）。