块中的附加行与清理代码中的附加参数

语境

在第35页的“ 清理代码”中，它说

这意味着if语句，else语句，while语句等中的块应为一行。该行可能是函数调用。这不仅使封闭函数较小，而且还增加了文档价值，因为在块中调用的函数可以具有很好的描述性名称。

我完全同意，这很有意义。

稍后，在第40页上，它介绍了有关函数参数的信息

函数的理想参数个数为零（尼拉度）。接下来是一个（单声道），紧接着是两个（双声道）。在可能的情况下，应避免使用三个参数（三重性）。超过三个（多义词）需要非常特殊的理由-因此无论如何都不应使用。争论很难。他们具有很大的概念力。

我完全同意，这很有意义。

问题

但是，通常我会发现自己从另一个列表创建了一个列表，而我将不得不忍受两个弊端之一。

我在代码块中使用了两行，一行用于创建事物，一行用于将其添加到结果中：

    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;
    }

或者，我在要向其中添加事物的列表的函数中添加了一个参数，从而使其“变差了一个参数”。

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

题

我没有看到哪些（缺点）优势，这些优势通常使它们之一更受欢迎？还是在某些情况下有这样的优势？在这种情况下，做出决定时我应该寻找什么？

这些准则只是指南针，而不是地图。他们为您指明了明智的方向。但是他们不能真正绝对地告诉您哪种解决方案是“最佳”的。在某个时候，由于您已经到达目的地，因此您需要停止走入指南针指向的方向。

干净的代码鼓励您将代码分成非常小的明显的块。这通常是一个好的方向。但是，如果达到极限（正如所引用建议的字面解释所暗示的那样），那么您将把代码细分为无用的小片段。实际上什么也没做，只是委托。这本质上是另一种代码混淆。

在“越小越好”与“过小无用”之间取得平衡是您的工作。问问自己哪种解决方案更简单。对我来说，这显然是第一个解决方案，因为它显然可以汇编一个列表。这是一个很好理解的成语。无需看另一个功能就可以理解该代码。

如果有可能做得更好，那就是要注意“将所有元素从一个列表转换到另一个列表”是一种常见的模式，通常可以通过使用功能map()操作来抽象出来。在C＃中，我认为它叫做Select。像这样：

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

函数的理想参数个数为零（尼拉度）

没有！一个函数的理想参数个数为1。如果为零，则表示您保证该功能必须访问外部信息才能执行操作。“叔叔”鲍勃误解了这一说法。

关于您的代码，您的第一个示例在块中只有两行，因为您要在第一行上创建一个局部变量。删除该分配，您将遵守以下干净代码准则：

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);

“清洁代码”建议是完全错误的。

在循环中使用两行或更多行。当它们是一些需要描述的随机数学时，将相同的两行隐藏在一个函数中是有意义的，但是当这些行已经具有描述性时，它什么都不做。“创建”和“添加”

您提到的第二种方法实际上没有任何意义，因为您不必为了避免这两行而添加第二个参数。

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接受列表并修改该列表，使函数不纯净且难以推理。方法名称中没有任何内容表明该方法仅添加到列表中。

我提供了第三种最佳选择：

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

而且，如果仅在一个地方使用它，则可以立即内联该方法，因为单行代码本身就很清楚，因此不需要用方法封装它即可赋予其含义。

一个参数版本更好，但不是主要因为参数数量多。

更好的最重要原因是它具有较低的偶联，这使其更有用，更易于推论，更易于测试，并且不太可能变成复制粘贴的克隆。

如果你向我提供CreateFlurp(BadaBoom)，我可以使用任何类型的收集容器：简单Flurp[]，List<Flurp>，LinkedList<Flurp>，Dictionary<Key, Flurp>，等。但是，有了CreateFlurpInList(BadaBoom, List<Flurp>)，我明天再问您，CreateFlurpInBindingList(BadaBoom, BindingList<Flurp>)以便我的viewmodel可以收到列表已更改的通知。！

另外一个好处是，更简单的签名更可能与现有的API相适应。您说您经常遇到问题

通常我发现自己是从另一个列表创建一个列表

只是使用可用工具的问题。最短，最有效和最佳的版本是：

var Flurps = badaBooms.ConvertAll(CreateFlurp);

这不仅让您编写和测试的代码更少，而且速度也更快，因为List<T>.ConvertAll()它足够聪明，可以知道结果将具有与输入相同的项目数，并将结果列表预先分配给正确的大小。虽然您的代码（两个版本）都需要增加列表。

牢记总体目标：使代码易于阅读和维护。

通常，可以将多行分组为一个有意义的功能。在这种情况下，请这样做。有时，您需要重新考虑您的一般方法。

例如，在您的情况下，将整个实现替换为var

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

可能是有可能的。或者你可能会做类似的事情

flups.Add(new Flurp(badaBoom))

有时，最干净，最易读的解决方案根本无法与任何一行兼容。因此，您将有两行。不要为了满足一些任意规则而使代码更难理解。

（我认为）第二个例子比第一个例子难理解。不仅仅是拥有第二个参数，还在于该参数已由函数修改。查找“清洁代码”对此有何评论。（现在没有手头的书，但是我很确定这基本上是“如果可以避免就不要这样做”）。