下面我刚才的问题有关的背后极长功能的理由，我想提出关于特定问题的代码 ，我为我的研究学习。 这是一个从Linux内核的功能这是相当长的（412线）和复杂的（一个MCC索引的133）。 基本上，这是一个漫长和嵌套switch语句
坦率地说，我想不出任何办法来改善这个烂摊子。 调度台显得既庞大，效率低下，以及任何子程序调用需要，以覆盖码大足段的参数的数目不可思议。
你想到的任何方式这个功能可以在一个更可读的方式被改写，而不会失去效率？ 如果没有，代码可读性似乎对你？
不用说，这会出现在我的研究中任何回答将给予充分的信贷 - 在这里和在提交的论文。
链接功能在网上浏览器源码
完全可怕的，恕我直言。 明显的一阶修正是使在开关每种情况下的函数的调用。 任何人都开始喃喃自语约效率之前，我只想说一个字 - “内联”。
编辑：是万一Linux的FPU模拟器的这部分代码？ 如果是这样，这是很老的代码，这是一个黑客让Linux在英特尔芯片的工作方式类似于386没有一个FPU。 如果是，它可能不是学者合适的研究，除了史学家！
我不认为函数是一个烂摊子。 我已经收到写这样一个烂摊子。
这个函数是翻译成表的代码由微处理器制造商。 这是非常低层次的东西，复制相应的硬件寄存器为特定的中断或故障的原因。 在这样的代码，你经常无法触摸还没有被硬件填写寄存器 - 可以导致总线错误。 这防止使用的代码是更一般的（如复制所有寄存器）。
我没看到什么似乎是一些代码重复。 然而，在这个级别（在中断级别运行），速度更重要。 我不会用提取方法的通用代码，除非我知道，所提取的方法将被内联。
顺便说一句，而你在那里（内核）的时候，一定要抓住这个代码的更改历史记录。 我有一个怀疑，你会发现这里再也没有出现过非常多的变化，因为它依赖于硬件。 变化在这种代码的时间自然会从大多数用户模式代码所经历的变化的性质完全不同。
这是那种会改变，例如，当一个新的统一的IO芯片实现的事情。 在这种情况下，改变是有可能被复制和粘贴并更改新副本，而不是修改现有的代码，以适应变化的寄存器。
有一种规律性的在这里，我怀疑一个领域的专家其实这感觉很连贯。
还具有在接近proximty变化允许立即目视检查。
我不认为有必要重构这个代码。
我想通过定义各种类的常量开始。 进入这个代码感冒，这是一个神秘的开关是什么; 如果开关反对命名常量，我就会有一个起点。
更新：你可以摆脱约70行，其中的情况下返回MAJOR_0C_EXCP; 只是让通过他们下降到程序的末尾。 由于这是内核代码我会提到，有可能是与一些性能问题，特别是如果订单的情况下已经进行了优化，但它至少会减少的代码，你需要处理的量。
我不知道很多关于内核或如何重新分解它们可能会奏效。
这使我想到的主要的是考虑该switch语句，打破各子一步到一个单独的功能与描述什么部分是做一个名字。 基本上，更具描述性的名称。
但是，我不认为这更多的优化功能。 它只是打破它在更小的功能，这可能会有所帮助......我不知道。
这是我的2美分。
