非常に長い関数の背後にある理論的根拠に関する以前の質問に続いて、私が研究のために研究しているコードについて具体的な質問を提示したいと思います。これは Linux カーネルの関数で、かなり長く (412 行) 複雑です ( MCC インデックスは 133)。基本的に、これは長くネストされた switch ステートメントです。
率直に言って、この混乱を改善する方法は思いつきません。ディスパッチ テーブルは巨大で効率が悪いように見えます。また、サブルーチン呼び出しには、十分な大きさのコード セグメントをカバーするために、想像を絶する数の引数が必要になります。
効率を落とさずに、この関数をより読みやすい方法で書き直す方法はありますか? そうでない場合、コードは読みやすいと思いますか?
言うまでもなく、私の研究に現れるどんな答えも、ここと提出された論文の両方で、完全なクレジットが与えられます.
その機能はハズレではないと思います。前にもこんなネタバレを書いたことがあります。
その関数は、マイクロプロセッサ メーカーのテーブルをコードに変換したものです。これは非常に低レベルのもので、特定の割り込みまたはエラーの理由に対して適切なハードウェア レジスタをコピーします。この種のコードでは、多くの場合、ハードウェアによって埋められていないレジスタにアクセスできません。バス エラーが発生する可能性があります。これにより、より一般的なコード (すべてのレジスタをコピーするなど) を使用できなくなります。
コードの重複のように見えるものを見ました。ただし、このレベル (割り込みレベルで動作) では、速度がより重要になります。抽出されたメソッドがインライン化されることがわかっていない限り、共通コードで Extract Method を使用しません。
ところで、そこ (カーネル) にいる間は、必ずこのコードの変更履歴を取得してください。ハードウェアに関連しているため、ここにはあまり多くの変更が加えられていないことがわかると思います。この種のコードの時間の経過による変化の性質は、ほとんどのユーザー モード コードが経験する変化の性質とはまったく異なります。
これは、たとえば、統合された新しい IO チップが実装されたときに変更されるようなものです。その場合、変更は、変更されたレジスタに対応するために既存のコードを変更するのではなく、コピー アンド ペーストして新しいコピーを変更する可能性があります。
まず、さまざまなクラスの定数を定義します。このコードに冷静に入ると、切り替えが何のためにあるのかは謎です。切り替えが名前付き定数に対して行われた場合、私は出発点を持っているでしょう。
更新：ケースがMAJOR_0C_EXCPを返す約70行を削除できます。単にそれらをルーチンの最後までフォールスルーさせてください。これはカーネルコードであるため、特にケースの順序がすでに最適化されている場合は、パフォーマンスの問題が発生する可能性がありますが、少なくとも処理する必要のあるコードの量は減ります。
ここにはある種の規則性があります。ドメインの専門家にとって、これは実際には非常に首尾一貫していると感じているのではないかと思います。
また、近接性にばらつきがあるため、すぐに目視検査できます。
このコードをリファクタリングする必要はないと思います。
まったく恐ろしい、私見。明らかな一次修正は、スイッチ内の各ケースを関数の呼び出しにすることです。誰かが効率についてつぶやき始める前に、「インライン化」という言葉を一言だけ言わせてください。
編集:このコードは Linux FPU エミュレーターの一部ですか? もしそうなら、これは非常に古いコードであり、FPU を持たない 386 のような Intel チップで Linux を動作させるためのハックでした。もしそうなら、歴史家を除いて、それはおそらく学者にとって適切な研究ではありません!
カーネルについて、またはそれらのリファクタリングがどのように機能するかについて、私はあまり知りません。
私の頭に浮かぶ主なことは、その switch ステートメントを使用して、各サブステップを、セクションが何をしているかを説明する名前を持つ個別の関数に分割することです。基本的に、よりわかりやすい名前です。
しかし、これで機能が最適化されるとは思えません。役立つかもしれない小さな機能に分割するだけです...わかりません。
それが私の2セントです。