代码应该有多复杂？

简单通常是更好的。请记住，其他人可能会在未来维护它。

编写代码时应考虑到普通程序员的维护和理解难度，使其易于维护和理解。

不必要的复杂性总是不好的。是的，编写一个能够完成200行函数工作的精简代码可能会很有趣。但请记住，您需要维护代码。短而复杂的代码维护起来非常困难。

有趣的是，代码复杂度最常用的衡量标准之一是嵌套深度。自动化代码分析器可能会将您的“If-then-else”解决方案分类为更加复杂的解决方案。
然而，我见过足够多你所描述的“WTF？”编码，通常会选择if-then-else方法。但请考虑一下：是否可以使用更加复杂和公式化的方法，将特别困难的组件拆分成具有良好命名的方法？如果您能够这样做（甚至重构以消除冗余），则可以避免算法的最糟糕方面，同时避免多级if-then-else结构。

Python之禅很好地解决了这个问题:

...

简单胜于复杂。

复杂胜于凌乱。

...

如果实现难以解释，则是一个糟糕的想法。

...

换句话说(正如其他人所说)，在规定的约束条件(时间、内存等)下，最简单的算法能够完成任务，就是最好的。显然，一个不能完成任务的更简单的算法是不够好的。如果你的代码因为使用了复杂的思想而变得更短，那么它就很复杂。如果没有人能够理解你的代码，那它就是复杂的；如果你很难向他们解释它(即使他们有数学博士学位)，那么它是个糟糕的想法。

...

特例并不足以打破规则。

虽然实用性胜过纯粹性。

...

通常会有很多特殊情况的代码在其生命周期中潜入最初的“纯”代码中。你应该抵制这种复杂性的建立，但在必要时接受它。

让代码更简单的另一个风险是你会被归为普通程序员的一堆中。你要考虑的是可读性/不可读性的问题。如果你在一周后回来，仍然可以轻松地阅读代码，那么我认为它已经足够简单了。

我曾见过非常优化的代码运行非常缓慢，而未经优化的代码运行速度很快，这是因为编译器知道计算机要如何工作，而编译器编写者首先关注易于优化的代码。也许你的150行算法编译后比20行版本运行时要快得多。你的20行算法可能会变得更慢，因为编译器不知道如何对其进行优化。
我还建议您将if-else版本放在20行算法版本的注释块中（或反之亦然），以便维护人员可以理解您的复杂版本试图做什么。将它们都放在代码中使得容易对两者进行性能测试（一旦两者都输入，就没有删除另一个的理由）。这也将有助于轻松迁移到其他语言/平台/编译器。您可能没有想到，但如果代码有效，它可能会存活几十年，并看到许多不同的编译器和平台。

尝试在你写完几周后请其他人审核你的“更复杂”的版本。判断复杂度是基于你自己阅读和向他人解释时的难度以及他们对代码的反应。

制作复杂的风险在于没有其他人能够理解它。在这种情况下，要清晰地进行注释，并引用一些资源来帮助其他人学习和理解它。
制作简单的风险在于有些人不想理解它，因为它太冗长了。

我认为问题是 - 复杂的代码是否更好？它是否更快，更可靠？目标是编写最佳程序，如果复杂的代码是最佳解决方案，那么您只需要编写更好的注释，以便您的继任者可以在未来管理代码。原则上，在任何情况下，代码应尽可能简单。