代码应该有多复杂？

如果你能用20行代码实现，并且适当地注释这些代码，我会说去做吧。不仅通过减少需要维护的代码使其更易于维护，而且还有助于让你的同行程序员变得更聪明。
预优化和巧妙的技巧是一回事，但聪明的算法一直都是公平竞争的。
但要将这些算法隔离在它们自己的函数中，并记得解释输入和输出变量！
必须引用的话：
“控制复杂性是计算机编程的本质。”（布莱恩·克尼根）

我认为将领域复杂性与基础技术复杂性分开是很重要的。

你希望使用计算机处理的某些领域特定功能本质上是复杂的，而有些则不是。例如，会计问题充满奇怪的规则，但大多数计算都相当简单。另一方面，根据类型，对金融证券进行估值可能涉及极其复杂的数学公式和大量模拟。大多数计算机系统实际上只是收集大量数据，但其中许多系统具有一些基础复杂算法。

另一方面，技术本身经常施加自己的复杂性。在PC上用C++编写大型程序可能是一项挑战。在互联网上编写基于Web的应用程序可能更糟糕。尝试确保容错性、性能或安全性往往会导致很多额外的复杂性。每种不同的技术都有助于或妨碍系统。

我们真正想做的是以最接近其固有领域或技术规范的最简形式表达代码。如果你正在编写操作系统，那么C是更易于使用的语言。如果你正在计算保险的复杂风险概率，那么面向矩阵的语言如APL可能更合适。如果你只是创建大量报告，那么最好选择一种简单的、面向报告的语法。

所以，如果你的150行if/else代码“匹配”问题表达得比20行巧妙的代码更好，那么它是一段更易于维护和扩展的代码。如果你从长远的角度来看待，编写可运行的代码很容易，保持其可维护性则是真正的挑战...
Paul.

它需要尽可能复杂。但它不能是复杂的，这是很大的区别。

嗯，如果代码足够大（参见大多数Java代码），仅仅由于数量的原因，它就会变得非常难以理解和维护。如果其他所有方面（性能等）都相等，并且简单算法和复杂算法之间的长度差异真的很大，我总是会选择复杂但简洁优雅的算法而不是简单但冗长的算法。假设两种算法都被证明是正确的，那么具有较少if语句和较少代码的算法不太可能存在微妙的实现错误，因此也不太可能需要维护。如果我是一个维护者，我宁愿花时间学习新算法，也不想学习某个非常冗长但无聊的算法的实现方式。

这要看情况。如果一个函数由150行if-then-else语句组成，特别是决策树很密集的情况下，我不想维护它。20行复杂的数学公式可能更好，也可能不是。理解起来可能需要时间，但更长的解决方案可能需要更长的验证时间。

理想情况下，你会找到一种更简单的方法来实现，但并非所有函数都能这样做。

如果你使用了20行代码，请用其中节省下来的130行代码来解释你正在使用的算法。如果你无法很好地解释它，请选择150行的解决方案。

对我来说，复杂并不一定意味着更多或更少的代码行。

完美的系统从来没有第一次就建成。你所能做的就是尽量避免做出太多复杂的决策，使自己陷入只能以一种方式完成事情的困境。

因此，在任何项目的初始版本中，我都喜欢保持复杂度低。如果你把它构建得尽可能复杂，那么理由（新的灵活性）将受到严重影响，而在开始时很少有人会理解它。这可能是好事或坏事。

如果你把它设计得过于简单（需要50%到70%的额外代码），它可能会存在性能问题。

随着系统的老化和成熟，复杂性似乎通过重构而增加。到那时，你可能会达到一个程度，某些代码可能永远不会再被触及，如果你真的要触及它，由于较低的接触频率，理解复杂性的成本将更低。

我喜欢用简单的步骤解决复杂的问题。如果不可能，复杂度也会相应增加。在另一个问题中，有一个关于知道何时“足够好”的观点。有时候多写一点代码（5-20%）可以显著抵消复杂性，这可能会更昂贵，需要重新学习或由其他人理解。

需要更好的算法通常是一个好问题，因为这意味着你的东西正在被使用，并且有新的需求需要处理。

对我来说，这与数据库抽象相同的复杂性，你必须知道何时使其更灵活，何时保持简单，并且最好通过构建它并在编写任何内容之前多次放弃它来学习。

只有在速度或空间提升确实必要时，复杂算法才是好的。不要费心编写一个运行时间为O(1)的花哨阶乘算法，因为25的阶乘基本上永远不会被使用。但是，如果代码位于最内层循环中，并且对该代码进行25%的加速将使整个应用程序提高20%，那就去做吧。

我承认我了解和喜欢数学和算法，但对我来说，一个150行的if/else混乱代码比任何可以用20行干净地表达的东西更加复杂和难以维护。请适当地记录代码，并引用论文、书籍或维基百科。