1

注: この質問では、主に C++ について言及しますが、これは他の言語にも当てはまる場合があります。

注: 再帰はないと仮定してください。

(非常に大きな関数がある場合) 関数をいくつかの小さな関数に「分割」するようによく言われますが、これは論理的ですか? これらの小さな関数のいずれかを使用しないという事実がわかっているとしたら、それはメモリとパフォーマンスの無駄であり、コードを読むときにコードをさらにジャンプする必要があるかもしれません。また、(仮想的に大きな) 関数を 1 回だけ使用する場合は、呼び出される場所に関数本体を挿入する必要があります (前回と同じ理由で、つまり、メモリ、パフォーマンス、および読んでいるときにコードをもっと飛び回るために)?つまり...関数を作成するか、作成しないか、それが問題です。

すべてに *編集*

私はまだすべての答えを調べていますが、これまで読んだことから仮説を立てました。

開発中に機能を分割するというのは正しいでしょうか、しかし、開発で一度使用する機能を作成するとともに、展開前に質問で提案したことを実行しますが、展開前にボディを挿入しますか?

4

3 に答える 3

1

パフォーマンスとメモリについてあまり心配する必要はありません。特に非常に薄い関数の場合は、コンパイラがその大部分を処理する必要があります。

私の目標は、通常、特定の関数呼び出しを読者のメモリ内で完全に置き換えることができるようにすることです。つまり、開発者は抽象化を純粋に扱うことができます。これを取る:

// Imagine here that these are real variable/function names as written by a
// lazy coder. I have seen code like this in the wild.
void someFunc(int arg1, int arg2) {
  int val3 = doFirstPart(arg1, field1);
  int val4 = doSecondPart(arg2, val3);
  queue.push(val4);
}

doFirstPart と doSecondPart のリファクタリングはほとんど役に立たず、理解を難しくする可能性があります。ただし、ここでの問題はメソッドの抽出ではありません。問題は、名前付けと抽象化が不十分なことです。読まなければならないかdoFirstPartdoSecondPart機能全体の要点が失われます。

代わりに、次のことを考慮してください。

void pushLatestRateAndValue(int rate, int value) {
  int rateIndex = calculateRateIndex(rate, latestRateTable);
  int valueIndex = caludateValueIndex(rateIndex, value);
  queue.push(valueIndex);
}

この不自然な例では、本当に深く掘り下げたい場合を除き、読む必要はありません。読むだけで、それが何をするかを正確に知ることができますcalculateRateIndexcalculateValueIndex

それとは別に、それは個人的なスタイルの問題かもしれません. すべてのビジネス「ステートメント」を別の関数に抽出することを好むコーダーがいることは知っていますが、それは少し読みにくいと思います。私の個人的な好みは、関数全体を一度に表示できるという利点がある「画面全体」(最大 25 行) よりも長い任意の関数から関数を抽出する機会を探すことです。短期記憶と一時的な理解の限界。

于 2013-01-19T01:28:13.687 に答える
1

これは本当に文脈に依存します。

関数のサイズと言うとき、実際には関数内の行の意味上の距離を意味します。1 つの関数が 1 つのことだけを行うようにすることをお勧めします。関数が 1 つのことしか実行せず、セマンティック距離が小さい場合は、関数を大きくしても問題ありません。

ただし、関数に多くのことをさせるのは良い習慣ではありません。コードのユーザーがジャンプする必要がないように、そのような関数をいくつかの小さな関数にリファクタリングして、適切な名前と適切なコード配置を使用することをお勧めします。その周り。

于 2013-01-19T01:27:06.220 に答える
1

ルーチンを 1 ページに収まる長さよりも長くしないことには、多くの正当な理由があります。ほとんどの人が常に考えているとは限らないことの 1 つは、デバッグ シンボルをデプロイしない限り (ほとんどの人はそうしません)、フィールドからのスタック トレースは分析がはるかに簡単で、原因に関する仮説に変わるということです。それが参照するルーチンは、分割することができなかったメソッドの 2,000 行のクジラのどこかでエラーが発生していることが判明した場合よりも小さいものです。

于 2013-01-19T01:40:03.670 に答える