代码应该有多复杂？
我正在研究可以帮助我编写更小但更复杂的代码的算法。 我可以设计一个用 20 行完成的算法，而不是编写 150 行 if-else 语句。 问题是许多算法可能很复杂，需要大量数学知识才能理解它们。 我也是这里唯一理解它们的人。
为了代码的可维护性，是像其他人一样编写代码更好，还是使用算法更好？
I'm studying about algorithms which can help me write smaller but more complex code. Instead of writing 150 lines of if-else statements, I can design an algorithm that does it in 20 lines. The problem is a lot of these algorithms can be complex and require a lot of math to understand them. I'm also the only one around here who understands them.
For maintainability of the code, would it be better to just write code like everyone else does, or is it better to use the algorithms?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（28）
正如爱因斯坦所说：
它既适用于代码，也适用于物理。
运用你的判断——它会变得更容易维护吗？ 通常，通过将大的 if/else 混乱减少为更小的东西，您可以删除不需要的极端情况，从而防止将来可能出现的错误。 当然，通过将一组明确的条件简化为仅适用的布尔逻辑的晦涩扭曲，当事情发生变化时，您可能会使事情变得更加难以维护。
编辑：
对于您引用的案例，如果该公式有效，那么它可能是更好的选择 - 您甚至可以发表评论引用来源。 不过，完全有可能该公式以前就存在，但为了解决特定情况而被删除。 这是版本控制存储库中的注释应该有所帮助的事情。
由于尚未有人发布链接，这里是他所指的 PID 算法的描述。
As Einstein said:
It applies to code as well as to physics.
Use your judgement - will it get easier to maintain? Often by reducing large if/else messes into something smaller you remove corner cases that didn't need to be there, preventing bugs that may have popped-up in the future. Of course by reducing a clear set of conditions into an obscure twist of boolean logic that only happens to work, you may be making things much more difficult to maintain when something changes.
EDIT:
With the case you cited, if the formula is going to work, then it's probably the better option - you can even leave a comment citing the source. It's entirely possible though, that the formula was there before, but was dropped to allow a specific case to be worked around. This is the sort of thing comments in your versioning repository should help with.
Since no one's posted a link yet, here's a description of the PID algorithm he's referring to.
代码编写一次，读取 10 次。 所以你应该尽量让它尽可能容易理解。
而且，调试比编写代码困难得多。 那么，当您已经投入所有脑力来编写复杂代码时，如何调试代码呢？
只要尝试遵循软件开发三定律：
Code is written once, and read 10 times. So you should try to make it as easy to understand as possible.
Also, debugging is much harder than writing code. So how can you ever debug your code when you already put all of your brainpower into writing complex code?
Just try to follow The Three Laws of Software Development:
Robert C. Martin 使用此漫画作为他的书《干净代码》的简介：
< img src="https://i.sstatic.net/WQYtD.jpg" alt="唯一有效的代码质量衡量标准：WTF/分钟">
（来源：osnews.com）
Robert C. Martin uses this comic as an introduction to his book Clean Code:
(source: osnews.com)
请记住，代码主要应该由人类理解......编译器负责让计算机理解。
Remember that code should primarily be understood by humans...compilers take care of making the computer understand.
这里的“复杂”程度可能有点冒险，但只要算法不需要数学博士学位来解决，
我会说继续使用算法。 确保提供有关算法名称的适当级别的文档，也许还有其工作原理的简短描述或有关该算法的文档的引用。
它将减少代码量，有望为应用程序提供一些额外的性能，并且有望鼓励您周围的一些程序员学习一些新东西以添加到他们的技能中。 另外，确实知道这些事情的程序员以后也有可能不会加入。
The level of "complex" can be a little dicey here, but as long as the algorithm doesn't require a PhD in mathematics to solve,
I'd say go ahead and use the algorithms. Make sure to put a decent level of documentation about the name of the algorithm, and maybe a short description of how it works or a reference to a document about it.
It will keep the amount of code down, hopefully give a little extra performance to the application, and it will hopefully encourage a few programmers around you to learn some new things to add to their repertoire. Plus there's always the chance that a programmer that does know these things won't be coming in later on.
好旧的报价....
Good old quote....
我不敢相信有人认为 150 行的东西比 20 行的东西更简单。
按照这 20 行代码，按如下方式保护您的同事：
记录每个数据结构不变量和每个重要循环不变量。 不是在注释中记录这些内容，而是在检查不变量的实际代码中记录这些内容。 可以在生产过程中关闭检查。
如果您在代码中使用数学公式或在代码中进行导出，请在注释（或静态字符串）中包含引用。 理想情况下，包括两份参考资料：一份可能在几秒钟内就可用的网络参考资料和一本可能会长期印刷并在大学图书馆中找到的受人尊敬的教科书。
如果理解你的代码需要特殊的专业知识（理解偏微分方程、物理学位、伽罗瓦理论，凡是你能想到的），那么为了保护自己，你可能希望去找你的管理层并说“我拥有这种特殊的专业知识，这使得它成为可能。”我可以编写更小的代码（因此更快、更可靠、更易于维护），但是当您必须替换我时，您将不得不雇用具有类似专业知识的人，您希望我做什么？ ” 如果您能告诉您的管理层如何轻松获得此类专业知识，将会很有帮助。 例如，很多拥有工程学位的人都可以学习偏微分方程，但伽罗瓦理论家的基础却相当薄弱。
PS 这是来自业余爱好项目的示例注释，以便我稍后可以调试自己的代码：
I can't believe anybody thinks 150 lines of anything is simpler than 20 lines of something.
Go with the 20 lines, and protect your coworkers as follows:
Document every data-structure invariant and every nontrivial loop invariant. Document these not in comments but in actual code that checks the invariants. The check can be turned off during production.
If you use math formulas in your code or to derive in your code, include references in comments (or static strings). Ideally include two references: a Web reference that's likely to be available in seconds and a well-regarded textbook that's likely to stay in print a long time and be found in university libraries.
If understanding your code requires special expertise (understanding of partial differential equations, a degree in physics, Galois theory, you name it), then to protect yourself you may wish to go to your management and say "I have this special expertise which makes it possible for me to write code that is smaller (and therefore faster, more reliable, and easier to maintain), but when you have to replace me you are going to have to hire someone with similar expertise. What do you want me to do?" It will be helpful if you can tell your management how easily such expertise can be obtained. For example, lots of people with engineering degrees can learn partial differential equations, but Galois theorists are rather thin on the ground.
P.S. Here's an example comment from a hobby project so I can debug my own code later:
尽可能复杂，仅此而已。
As complex as it has to be and no more.
这实际上取决于复杂的含义。 如果你的“简单”算法是 150 行几乎相同的代码，我的眼睛会变得呆滞，我将无法理解它。 如果您将这些条件放入矩阵或其他内容中，然后您的代码是一个读取矩阵并做出决策的循环，我会更好地理解它，即使循环可能不如一堆 if/else 语句“简单”。
如果基本上您正在谈论一个 Perl 程序，您可以在一行中完成所有操作，并大量使用默认变量 $_ 我会说坚持使用更长、更详细的版本。
如果有一个公认的公式来做某事，那么您可以使用公认的公式。 如果有一个需要 3 或 4 行的简单代数公式，并且有一个需要一行的复杂微分方程，则应该使用简单代数公式。 在评论中提到的情况下，我认为 PID 算法比 150 行 if/else 代码“更简单”。 我不认为你使用算法来掩盖任何东西，而是你在问题领域使用标准技术。 只需确保对其进行良好注释，甚至可能包含描述该公式的网页链接。
It really depends on what complex means. If your "simple" algorithm is 150 lines of almost the same code, my eyes will glaze over and I won't be able to understand it. If you put those conditions in a matrix or something and your code is then a loop to read the matrix and make decisions, I will understand it better even though the loop may be less "simple" then a bunch of if/else statements.
If basically you are talking about a Perl program where you do everything in one line making huge use of the default variable $_ I would say stick with the longer more verbose version.
If there is an accepted formula to do something then you can use the accepted formula. If there is a simple algebraic formula that takes 3 or 4 lines and there is a complex differential equation that takes one line, you should use the simple algebraic formula. In the case mentioned in the comments, I think a PID Algorithm is "simpler" than 150 lines of if/else code. I don't think you are using the algorithm to obscure anything, but rather you are using standard techniques in the domain of the problem. Just make sure to comment it well and maybe even include a link to a web page describing the formula.
在我看来，通过 100 行 if/else 语句找到方法通常（在我看来）对维护者的耐力来说比花同样的时间理解更好的算法（应该在注释中进行解释或链接）并最终验证该算法更难20 行执行确实执行了这一行。 它还具有在职教育的好处，这使得工作变得更有趣（从积极的意义上来说），并且通常也有更好的执行情况（更少的资源使用）。
您应该避免的聪明做法是滥用语言而没有实际好处的“聪明黑客”形式。 您应该拥抱的聪明之处是始终使用适合工作的最佳算法。
编辑：关于 PID 示例：我发现很难想象 PID 的功能可以被一堆 if-else 语句合理地替代。 if-else 解决方案总是工作得更差（不太平滑的转换），很难维护，也很难调整（调整 PID 部分对于获得所需的行为非常重要）。 我想补充一点，理解 PID 并不难，即使你不懂数学，也可以很容易地查到。
Finding the way through 100 lines of if/else statements is often (in my opinion) harder on the maintainer's stamina than spending the same time understanding a better algorithm (which should be explained or linked to in the comments) and finally just verifying that the 20 lines of the implementation do indeed execute that one. It also has the benefit of education on the job, which makes it that much more interesting (in a positive sense), and often also better execution profile (less use of resources).
The cleverness you should avoid is in the form of "clever hacks" that abuse the language without actual benefit. The cleverness you should embrace is always using the best algorithm for the job.
edit: Regarding the PID example: I find it very hard to imagine that the functionality of a PID can be sanely substituted by a bunch of if-else statements. The if-else solution will always work worse (less smooth transitions), be very hard to maintain, and very hard to tune (tuning the PID parts is very important to get the desired behaviour). I'd like to add that understanding PID is not too hard, even if you do not know the math, which can be easily looked up.
越简单通常越好。 请记住，有一天其他人可能不得不维护它。
Simpler is usually better. Remember that other people will probably have to maintain it someday.
以对于处理代码的普通程序员来说最容易维护和理解的方式编写代码。
Write the code in a way that is easiest to maintain and understand for the average programmer who works on your code.
不必要的复杂性总是不好的。 是的，编写一个出色的单行代码来完成 200 行函数的工作可能会很有趣。 但请记住，您应该维护代码。 简短而复杂的代码很难维护。
Unneeded complexity is always bad. Yes it could be fun to write a brilliant one liner that does the work of a 200 line function. But remember that you should maintain the code. And short complex code is hell to maintain.
有趣的是，代码复杂性最常见的衡量标准之一是嵌套深度。 自动代码分析器很可能将您的“If-then-else”解决方案归类为比您的公式化解决方案更复杂。
然而，我已经看够了“WTF？” 根据您描述的编码，我通常会采用 if-then-else 方法。 但考虑一下这一点； 是否可以使用更复杂、更公式化的方法，但将特别困难的组件分解为命名良好的方法？ 如果您可以这样做（甚至可能进行重构以消除冗余），您也许能够避免算法中最糟糕的方面，同时也避免多级 if-then-else 结构。
Interestingly enough, one of the most common measures of code complexity is the depth of nesting. Your "If-then-else" solution may well be classified as more complex by an automated code analyzer than your formulaic one.
However, I've seen enough of the "WTF?" coding that you describe that I would generally go for the if-then-else approach. But consider this; is is possible to use your more complex, formulaic approach but to split out particularly difficult components into well-named methods? If you can do so (possibly even refactoring to eliminate redundancy) you may be able to avoid the worst aspects of your algorithm while avoiding a multi-level if-then-else structure as well.
Zen of Python 很好地解决了这个问题：
换句话说（正如其他人所说），最简单的算法将在强加的约束下完成工作（时间、记忆等）是最好的。 显然，一个不能完成工作的更简单的算法还不够好。 如果你的代码因为使用复杂的想法而较短，那么它就很复杂。 如果没有其他人能够理解您的代码，那么它就很复杂，并且如果您很难向他们解释它（即使他们拥有数学博士学位也能理解它），这是一个坏主意。
通常有很多特殊情况的代码在其生命周期中渗透到最初的“纯”代码中。 您应该与这种建筑复杂性作斗争，但在必要时接受它。
The Zen of Python does a pretty good job of addressing this issue:
In other words (and as others have said), the simplest algorithm that will get the job done under the imposed constraints (time, memory, etc.) is the best one. Obviously a simpler algorithm that doesn't get the job done isn't good enough. If your code is shorter because it uses complex ideas, it's complex. If no one else can understand your code, it's complicated and if you have a hard time explaining it to them (even if they would understand it with a PhD in math), it's a bad idea.
There's often a lot of special case code that creeps into originally "pure" code during its lifetime. You should fight this building complexity, but accept it when it's necessary.
使代码更简单的另一个风险是你会陷入普通程序员的行列。 您正在寻找的行是可读/不可读的代码。 如果您可以在一周后回来并且仍然可以轻松阅读代码，那么我会说它很简单。
The other risk of making the code simpler is that you'll get lumped into the pile of average coders. The line you're looking for is readable/unreadable code. If you can come back in a week and still easily read the code, then I would say it's simple enough.
我见过非常优化的代码运行得非常慢，而未优化的代码运行得很快，这是因为编译器知道计算机想要如何工作，而编译器编写者首先关注的是易于优化的代码。
您的 150 行算法编译成的运行时速度可能比 20 行版本快得多。 你的 20 行算法最终可能会变慢，因为编译器不知道如何优化它。
我还建议您可能希望将 if-else 版本放在 20 行算法版本上方的注释块中（反之亦然），以便维护人员可以理解您的复杂版本想要做什么。 将它们都放在代码中也可以轻松地对两者进行性能测试（一旦您将它们都输入了，就没有理由删除另一个）。 这也将允许轻松迁移到其他语言/平台/编译器。 您可能没有想到，但如果代码有效，它很可能会存在数十年，并出现在许多不同的编译器和平台上。
I've seen very optimized code run very slowly, and the unoptimized code run quickly, and that's because compilers know how the computer wants to work, and compiler writers focus on the easy to optimize code first.
It may be that your 150 line algorithm compiles into something that's much faster at run time than your 20 line version. Your 20 line algorithm may end up being slower because the compiler doesn't know how to optimize it.
I would also suggest that you might want to put the if-else version in a comment block above the 20-line algorithm version (or vice versa) so that maintainers can understand what your complex version is trying to do. Having them both in the code makes it easy to performance test the two as well (and once you've typed them both in, there's no reason to delete the other). This will also allow for easy migration to other languages/platforms/compilers going forward. You may not expect it, but if the code works, it's likely to live on for decades and see many different compilers and platforms.
在你写完几周后，尝试让其他人审查你的“更复杂”的版本。 根据您阅读并向他人解释代码的难度以及他们对代码的反应来判断复杂性。
Try and have your "more complex" version reviewed by others, a few weeks after you've written it. Judge the complexity on how difficult is it for you to read and explain it to others, and their reaction to the code.
让它变得复杂的风险是没有其他人能够理解它。 在这种情况下，请清楚地评论并引用一些有助于其他人学习和弄清楚的来源。
让它变得简单的风险是有人不想理解它，因为它太长了。
The risk of making it complex is that nobody else will understand it. In this case, comment it clearly and cite some sources that will help someone else learn and figure it out.
The risk of making it simple is that someone won't want to understand it because it is lengthy.
我认为问题是 - 复杂的代码更好吗？ 它更快、更可靠吗？ 我们的目标是编写最好的程序，如果复杂的代码是最好的解决方案，那么你只需要编写更好的注释，以便你的继任者将来可以管理代码。 原则上，在任何给定情况下，代码都应该尽可能简单。
I think the question is - Is the complex code any better? Is it faster, more reliable? The goal is to write the best programs, if the complex code is the best solution then you just have to write better comments so that your successor can manage the code in the future. In principal the code should be as simple as possible in any given situation.
如果你能用 20 行来做，然后正确地注释这些行，我会说那就去做吧。 您不仅可以通过减少需要维护的代码来使其更容易维护，而且还可以帮助您的程序员同事变得更加聪明。
预优化和巧妙的黑客攻击是一回事，但智能算法一直都是公平的游戏。
但请将这些算法隔离在它们自己的函数中，并记住解释输入和输出变量！
强制性报价：
If you can do it on 20 lines and then properly comment those lines I would say go for it. Not only are you making it easier to maintain by having less code to maintain, but you are also contributing to making your fellow programmers smarter.
Pre-optimizations and clever hacks is one thing but smart algorithms is and have always been fair game.
But keep those algorithms isolated in their own functions and remember to explain the input and output variables!
Obligatory quote:
我认为将领域复杂性与底层技术复杂性分开非常重要。
您希望使用计算机实现的某些特定领域的功能本质上很复杂，而有些则不然。 例如，会计问题充满了奇怪的规则，但大多数计算都相当简单。 另一方面，根据类型，对金融证券进行估值可能包括非常复杂的数学公式和大量的模拟。 大多数计算机系统实际上只是收集大量数据，但其中许多系统都有一些底层的复杂算法。
另一方面，技术往往会带来自身的复杂性。 用 C++ 为 PC 编写大型程序可能是一项挑战。 为 Internet 编写基于 Web 的应用程序可能会更糟糕。 试图确保容错性、性能或安全性通常会导致复杂性大大增加。 每种不同的技术都会帮助或阻碍系统。
我们真正想做的是以最简单的形式表达代码，最接近其固有领域或技术规范。 如果您正在编写操作系统，那么 C 是一种更容易使用的语言。 如果您正在计算复杂的保险风险概率，那么像 APL 这样的面向矩阵的语言可能更合适。 如果您只是创建大量报告，那么具有面向报告的简单语法的报告是最佳选择。
因此，如果你的 150 行 if/else 内容比 20 行巧妙的代码更能“匹配”问题的表达方式，那么它就是一段更易于维护和消耗的代码。 如果你从长远的角度来看，编写运行代码很容易，但保持这种方式才是真正的挑战……
保罗。
I think it is important to separate the domain complexity from the underlying technical complexity.
Some domain-specific functionality for which you would like to use the computer is intrinsically complex, some is not. For example, accounting problems are full of weird rules, but most of the computations are fairly simple. Valuating financial securities on the other hand, depending on the type, can include hugely complex mathematical formulas and lots and lots of simulations. Most computer systems are really just collecting large amounts of data, but many of them have a few underlying complex algorithms.
Technology on the other hand often imposes its own complexity. Writing a big program in C++ for a PC can be a challenge. Writing a web based application for the Internet can be far worse. Trying to insure fault-tolerance, performance or security often causes a great deal of added complexity. Each different technology helps or hinders the system.
What we really want to do, is express the code in it's simplest possible form that is closest to its inherent domain or technical specification. If you're writing an operating system, then C is an easier language to use. If you're working out complex risk probabilities for insurance than a matrix-oriented language like APL may be more appropriate. If you're just creating massive reports, than something with a simple syntax oriented towards reporting is best choice.
So if your 150 lines of if/else stuff "matches" the way the problem is expressed far better than 20 clever lines, it is a far more maintainable and expendable bit of code. If you take a long-term perspective, writing running code is easy, it's keeping it that way that is the real challenge ....
Paul.
它需要尽可能复杂。 不可能是复杂的、巨大的差异。
It needs to be as complex as necessary. What it can't be is complicated, big difference.
嗯，如果代码变得足够大（请参阅大多数 Java 代码），那么由于代码量太大，代码可能会变得非常难以理解和维护。 如果其他所有条件（性能等）相同，并且简单算法和复杂算法之间的长度差异确实很大，那么我总是会选择复杂但简洁而优雅的算法，而不是简单但冗长的算法。 假设这两种算法都被证明是正确的，那么 if 语句和总体代码较少的算法不太可能出现微妙的实现错误，因此不太可能需要维护。 如果我是一名维护者，我宁愿花时间学习一种新算法，也不愿学习别人如何实现一些长得可笑但无聊的算法。
Well, code can get pretty hard to understand and maintain just due to sheer volume if it gets large enough (see most Java code). If all else (performance, etc.) is equal and the difference in length between the simple and complex algorithm is really drastic, I'd always go with the complex but concise and elegant algorithm over the simple but verbose one. Assuming both algorithms are proven to be correct, the one with less if statements and less code overall is less likely to have subtle implementation bugs and therefore less likely to ever require maintenance. If I were a maintainer, I'd much rather spend my time learning a new algorithm than learning how someone implemented some ridiculously long but boring algorithm.
依靠。 我不想维护 150 行 if-then-else 语句来组成一个函数，特别是在决策树很密集的情况下。 20 行复杂的数学可能会更好，也可能不会更好。 理解可能需要时间，但更长的解决方案可能需要更长的时间来验证。
理想情况下，您会找到一种方法以更少和更简单的行来完成此操作，但并非所有函数都以这种方式工作。
如果您确实使用这 20 行，请使用注释中保存的 130 行中的一些来解释您正在使用的算法。 如果你不能很好地解释它，请使用 150 行的解决方案。
Depends. I wouldn't want to have to maintain 150 lines of if-then-else statements making up a function, particularly if the decision tree is dense. 20 lines of complicated math may or may not be better. It may take time to understand, but the longer solution might take even longer to verify.
Ideally, you'd find a way to do it in fewer and simpler lines, but not all functions work that way.
If you do use the 20 lines, use some of the 130 lines saved on comments to explain what algorithm you're using. If you can't explain it well, go with the 150-line solution.
对我来说，复杂并不一定意味着更多或更少的代码行。
完美的系统永远不会是第一次构建的。 您所能做的就是尽量不要做出太多复杂的决定，这些决定会让您以一种方式做事。
因此，我喜欢在任何项目的初始版本中保持较低的复杂性。 您构建某些东西（新的灵活性）的原因受到严重影响。 如果你让它尽可能复杂，那么一开始就会很少有人理解它。 这可能是好事，也可能是坏事。
如果你让它太简单（并且代码增加了 50% 到 70%），则可能会出现性能问题。
随着系统的老化和成熟，复杂性似乎是通过重构而出现的。 到那时，您可能会达到某些代码可能永远不会再被触及的地步，如果您曾经这样做过，那么由于触及它的频率较低，理解复杂性的成本将会降低。
我喜欢用简单的步骤解决复杂的问题。 如果不可能，复杂性就会相应增加。 另一个问题中有一点是关于知道什么时候“足够好”。 有时，多一点代码（5-20%）可以显着抵消复杂性，这可能会导致某人重新学习或理解的成本更高。
需要更好的算法通常是一个好问题，因为这意味着您的东西正在被使用并且有新的需求需要处理。
对我来说，这与适用于数据库抽象的复杂性相同，您必须知道何时使其更加灵活，何时使其保持简单，并且最好通过构建它来学习，并在编写数据库之前大量废弃它。任何东西的单行。
Complex does not necessarily mean more or less lines of code to me.
The perfect system is never built the first time. All you can do is try not to make too many complex decisions that tie you into doing things one way.
For that reason I like to keep complexity low during the initial versions of any project. The reason you built something (new flexibility) is severly impacted. If you make it as complex as possible fewer people will understand it at the beginning. That could be a good or bad thing.
If you make it too simple (and 50 to 70% more code) it may have performance issues.
As a system ages and matures, the complexity seems to come in through re-factoring. By then you can reach a point where some code may never be touched again, and if you ever do, the costs to understand the complexity will be lower due to the lower frequency of touching it.
I like solving complex problems with simple steps. Where it isn't possible, the complexity increases accordingly. There was a point in another question about knowing when its "good enough". Sometimes a bit more code (5-20%) can offset the complexity significantly, which may be more expensive to re-learn or understand by someone.
Needing a better algorithm is usually a good problem because it means your stuff is being used and theres new demands to be dealt with.
This is the same sort of complexity that applies to Database Abstraction for me, you have to know when to make it more flexible, and when to keep it simple, and its best learnt through building it, and scrapping it a lot before you write a single line of anything.
仅当确实需要提高速度或空间时，复杂的算法才是好的。 不要费心编写一个在 O(1) 中运行的奇特阶乘算法，因为大约 25 的阶乘基本上永远不会被使用。 但是，如果代码位于最内层循环，并且此代码中 25% 的加速将使整个应用程序提高 20%，那么就继续吧。
Complex algorithms are good only if the speed or space boost is actually necessary. Don't bother writing a fancy factorial algorithm that runs in O(1) because a factorial about 25 is basically never going to be used. However if the code is in the innermost loop and a speedup for 25% in this code will improve the entire application by 20% then go for it.
我承认我了解并喜欢数学和算法，但对我来说，150 行 if/else 的混乱比任何可以用 20 行清晰表达的东西都要复杂和难以维护。 正确记录代码并添加对论文、书籍或维基百科的引用。
I admit to knowing and liking maths and algorithms, but for me a 150-line if/else mess is way more complex and hard to maintain than anything that can be expressed cleanly in 20 lines. Document the code properly and put in references to papers, books, or Wikipedia.