你写过很长的函数吗？ 如果是这样，为什么？
我正在写一个关于极端的学术项目Linux 内核中的长函数。
为此，我正在寻找非常长（几百行代码）的现实函数的示例，您不会认为它们是糟糕的编程（即，它们不会从分解或调度的使用中受益）桌子）。
你曾经写过或者见过这样的代码吗？ 您可以发布或链接到它，并解释为什么它这么长吗？
我从这里的社区得到了惊人的帮助 - 任何将被纳入该项目的想法都将得到适当的认可。
谢谢，
乌迪
I am writing an academic project about extremely long functions in the Linux kernel.
For that purpose, I am looking for examples for real-life functions that are extremely long (few hundreds of lines of code), that you don't consider bad programming (i.e., they won't benefit from decomposition or usage of a dispatch table).
Have you ever written or seen such a code? Can you post or link to it, and give explanation of why is it so long?
I have been getting amazing help from the community here - any idea that will be taken into the project will be properly credited.
Thanks,
Udi
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
我写过的最长的函数都有一个共同点，那就是非常大的 switch 语句。 有时，当您必须打开一长串项目时，如果您尝试将某些选项重构为单独的函数，只会使事情变得更难以理解。 拥有大型 switch 语句会使循环复杂度达到顶峰，但它通常比替代实现更好。
The longest functions that I have ever written all have one thing in common, a very large switch statement. There are times, when you have to switch on a long list of items and it would only make things harder to understand if you tried to refactor some of the options into a separate function. Having large switch statements makes the Cyclomatic complexity go through the roof, but it is often better than the alternative implementations.
这是我被解雇前的最后一次。
It was the last one before I got fired.
之前的工作：一份非常长的案例陈述，IIRC 1000+行。 这远早于物体出现。 每个选项只有几行长。 如果把它分解的话，事情就变得不那么清楚了。 实际上有一对这样的例程对相同的底层数据类型集执行不同的操作。
抱歉，我不再有代码了，而且无论如何，它也不是我可以发布的。
A previous job: An extremely long case statement, IIRC 1000+ lines. This was long before objects. Each option was only a few lines long. Breaking it up would have made it less clear. There were actually a pair of such routines doing different things to the same underlying set of data types.
Sorry, I don't have the code anymore and it isn't mine to post, anyway.
我认为不可怕的最长函数是自定义 CPU VM 的关键方法。 与 @epotter 一样，这涉及一个大的 switch 语句。 事实上，我想说很多我发现无法被彻底分解或提高可读性的方法都涉及 switch 语句。
The longest function that I didn't see as being horrible would be the key method of a custom CPU VM. As with @epotter, this involved a big switch statement. In fact I'd say a lot of method that I find resist being cleanly broken down or improved in readability involve switch statements.
不幸的是，如果这种类型的子例程是在构建步骤中使用某种代码生成器自动生成的，那么您通常不会发现这种类型的子例程被签入或发布到某处。
因此，请寻找具有从另一种语言生成的 C 的项目。
Unfortunately, you won't often find this type of subroutine checked in or posted somewhere if it's auto-generated during a build step using some sort of code generator.
So look for projects that have C generated from another language.
除了性能之外，我认为内核空间中的调用堆栈的大小是8K（请验证大小）。 另外，据我所知，内核中的代码是相当具体的。 如果某些代码将来不太可能被重用，那么考虑到函数调用开销，为什么还要将其作为函数呢？
Beside the performance, I think the size of the call stack in Kernel space is 8K (please verify the size). Also, as far as I know, code in kernel is fairly specific. If some code is unlikely to be re-used in the future why bother make it a function considering function call overhead.
我可以想象，当速度很重要时（例如在内核中持有某种锁时），您不会希望因为进行函数调用而产生开销而分解函数。 编译时，必须将参数压入堆栈，并在返回之前将数据弹出。 因此，出于效率原因，您可能拥有较大的函数。
I could imagine that when speed is important (such as when holding some sort of lock in the kernel) you would not want to break up a function because of the overhead due to making a functional call. When compiled, parameters have to be pushed onto the stack and data has to be popped off before returning. Therefor you may have a large function for efficiency reasons.