重构以更高的LOC结束是否有意义？[关闭]

在某些情况下，比起更简洁的代码，更冗长的代码（如更逻辑的语句）更干净吗？

为了回答这个问题，让我们以发生在我身上的真实世界为例。在我维护的C＃库中，我有以下代码：

TResult IConsFuncMatcher<T, TResult>.Result() =>
    TryCons(_enumerator) is var simpleMatchData && !simpleMatchData.head.HasValue
        ? _emptyValue.supplied
            ? _emptyValue.value
            : throw new NoMatchException("No empty clause supplied");
        : _recursiveConsTests.Any() 
            ? CalculateRecursiveResult() 
            : CalculateSimpleResult(simpleMatchData);

与同龄人讨论时，一致的结论是，嵌套的三元表达式以及对的“巧妙”使用会is var导致简洁但难以阅读的代码。

因此，我将其重构为：

TResult IConsFuncMatcher<T, TResult>.Result()
{
    var simpleMatchData = TryCons(_enumerator);

    if (!simpleMatchData.head.HasValue)
    {
        return _emptyValue.supplied
            ? _emptyValue.value
            : throw new NoMatchException("No empty clause supplied");
    }

    return _recursiveConsTests.Any() 
        ? CalculateRecursiveResult() 
        : CalculateSimpleResult(simpleMatchData);
}

原始版本仅包含一个带有隐式的复合表达式return。现在，新版本包含一个显式变量声明，一个if语句和两个explicit returns。它包含更多的语句和更多的代码行。但是我咨询过的每个人都认为它更易于阅读和推理，这是“干净代码”的关键方面。

因此，您的问题的答案是一个明确的“是”，比简洁的代码更冗长的代码更简洁，因此是有效的重构。

1. LOC与代码质量之间缺乏相关性。

重构的目的是提高一段代码的质量。

LOC是一个非常基本的指标，有时与一段代码的质量相关：例如，具有数千个LOC的方法可能会出现质量问题。但是，应该指出，LOC并不是唯一的度量标准，并且在许多情况下缺乏与质量的相关性。例如，4 LOC方法不一定比6 LOC方法更具可读性或可维护性。

2.一些重构技术包括添加LOC。

如果您列举了一系列重构技术，则可以轻松地发现那些有意添加 LOC的技术。例子：

• 用符号常量替换幻数。
• 提取变量。

两者都是非常有用的重构技术，并且在考虑是否使用它们时，它们对LOC的影响是完全无关的。

避免使用LOC。

LOC是一个危险的指标。它非常容易测量，并且很难正确解释。

在您熟悉代码质量测量技术之前，请首先考虑避免测量LOC。大多数情况下，您不会获得任何相关信息，并且在某些情况下，它会误导您降低代码质量。

如果您想查看仅使源代码的字节数或LoC数最小化的最终结果，请查看提交给Stack Exchange Code Golf网站的提交。

如果以这种方式减少源代码，您很快就会陷入混乱。即使您是编写此类代码的人，并且当时对它完全了解，但六个月后返回时，您的效率如何？没有证据表明这样的最少代码实际上可以更快地执行。

代码的编写方式应使您团队中的任何成员都可以查看它，并立即了解它在做什么。

是的，重构肯定会导致更多的代码行。

IMO最常见的情况是，当您使用非通用代码并使之更加通用/灵活时。轻松地生成代码会使代码行显着增加（有时增加两倍或更多）。

如果您希望新通用代码被其他人（而不是作为内部软件组件）用作库，那么通常您最终会添加单元测试代码和代码内文档标记，这将再次增加代码行。

例如，这是每个软件开发人员都会遇到的非常常见的情况：

• 您的产品需要在两周内提供紧急的高优先级新功能或错误修复或增强功能（或在您认为项目大小/公司规模/等重要的任何时间范围内）
• 您会努力工作并按时交付XYZ，它就可以正常工作。恭喜你！做得好！
• 在开发XYZ时，您现有的代码设计/实现并不真正支持XYZ，但是您可以将XYZ填充到代码库中
• 问题是，填充程序很丑陋，并且具有可怕的代码气味，因为您做了一些棘手的/聪明的/丑陋的/不好的做法，但有点工作
• 当您以后找到时间时，可以重构代码，这可能会更改许多类或添加新的类层，并且您的新解决方案“正确”，并且不再具有不良的代码气味...但是， “正确的方式”现在占用更多的代码行。

我想到了一些具体的例子：

• 对于命令行界面，您可以有5000行if / else-if代码，也可以使用回调...每个回调都小得多，并且更易于阅读/测试/验证/调试/等，但是如果您计算编写丑陋的5000行if / else-if代码可能会更小
• 对于支持N种处理方法的处理代码段，您可以再次使用看起来最丑陋的if / else语句。
  • 或者您可以切换到更好/更好的回调，但是回调需要更多的代码行（尽管仍然是编译时）
  • 或者您可以进一步抽象并制作可以在运行时更改的插件。插件很好，因为您不必为每个新插件或对现有插件进行修改而重新编译主产品。并且您可以发布API，以便其他人可以扩展产品。但是，插件方法再次使用了更多的代码行。
• 为GUI创建一个很棒的新窗口小部件
  • 您或同事注意到，新的小部件非常适合XYZ和ABC，但现在该小部件已紧密集成，仅适用于XYZ
  • 您重构了窗口小部件以使其同时适用，但是现在总代码行增加了