他の関数のみを呼び出す関数。これは良い習慣ですか？

現在、多くの異なるセクション（すべて異なる書式設定が必要）を含む一連のレポートに取り組んでおり、コードを構造化する最適な方法を見つけようとしています。過去に行った同様のレポートには、レポートのすべてのデータ操作と書式設定を行う非常に大きな（200行以上の）関数があり、ワークフローは次のようになります。

DataTable reportTable = new DataTable();
void RunReport()
{
    reportTable = DataClass.getReportData();
    largeReportProcessingFunction();
    outputReportToUser();
}

これらの大きな機能を小さなチャンクに分割できるようにしたいのですが、再利用できない機能が何十個もあり、同様の機能を「ここですべて実行」するだけで済むのではないかと心配しています。次のように、これらすべての小さな関数を呼び出します。

void largeReportProcessingFunction()
{
    processSection1HeaderData();
    calculateSection1HeaderAverages();
    formatSection1HeaderDisplay();
    processSection1SummaryTableData();
    calculateSection1SummaryTableTotalRow();
    formatSection1SummaryTableDisplay();
    processSection1FooterData();
    getSection1FooterSummaryTotals();
    formatSection1FooterDisplay();

    processSection2HeaderData();
    calculateSection1HeaderAverages();
    formatSection1HeaderDisplay();
    calculateSection1HeaderAverages();
    ...
}

または、さらに一歩進んだ場合：

void largeReportProcessingFunction()
{
    callAllSection1Functions();

    callAllSection2Functions();

    callAllSection3Functions();
    ...        
}

これは本当に良い解決策ですか？組織的な観点から私はそれがそうであると思います（すなわち、すべてはそうでなければそうであるかもしれないよりもはるかに組織化されます）が、コードの読みやすさに関して私は確信していません（潜在的に他の関数を呼び出すだけの関数の大きなチェーン）。

考え？

これは一般に機能分解と呼ばれ、正しく行われた場合は一般的に行うのが良いことです。

また、関数の実装は、抽象化の単一レベル内にある必要があります。を使用する場合largeReportProcessingFunction、その役割は、どの処理手順をどの順序で実行するかを定義することです。これらの各ステップの実装は、下の抽象化レイヤー上にありlargeReportProcessingFunction、それに直接依存するべきではありません。

ただし、これは命名の悪い選択であることに注意してください。

void largeReportProcessingFunction() {
    callAllSection1Functions();
    callAllSection2Functions();
    callAllSection3Functions();
    ...        
}

あなたが見るcallAllSection1Functions名前は実際には抽象化を提供しない名前です。なぜならそれは実際にそれが何をするかではなく、むしろそれをどのように行うかを言うからです。processSection1代わりに呼び出すか、コンテキストで実際に意味のあるものを呼び出す必要があります。

C＃を使用しているとおっしゃいましたが、オブジェクト指向言語を使用しているという事実を利用して、構造化されたクラス階層を構築できるのでしょうか。たとえば、レポートをセクションに分割することが理にかなっている場合は、Sectionクラスを作成し、クライアント固有の要件に合わせて拡張します。

非対話型のGUIを作成しているかのように考えるのは理にかなっているかもしれません。作成するオブジェクトを、異なるGUIコンポーネントであるかのように考えてください。基本的なレポートがどのようになるかを自問してください。複雑なものはどうですか？拡張ポイントはどこにあるべきですか？

場合によります。作成しているすべての関数が本当に単一の作業単位である場合、それらが呼び出し関数の1〜15行、16〜30行、31〜45行である場合は問題ありません。20個すべてをチェックする検証機能を備えたレポートに20個のフィルターがある場合、1つのことをすれば、長い関数は悪ではありません。それは問題ありません。フィルターまたはフィルターのグループごとに分割すると、実際のメリットが得られないだけの複雑さが追加されます。

多くのプライベート機能があると、自動化された単体テストがより難しくなります。そのため、一部の人はそれを回避しようとしますが、テストに対応するためにより大きく複雑なデザインを作成する傾向があるため、これはかなり悪い推論です。

C＃を使用しているので、オブジェクトをもっと試してみてください。後続の関数が依存する「グローバル」クラス変数を持つことで、手続き的にコーディングしているように見えます。

ロジックを個別の関数に分割することは、すべてのロジックを単一の関数に含めるよりも間違いなく優れています。関数が動作するデータをいくつかのオブジェクトに分割することで、さらに処理を進めることもできます。

レポートデータを渡すことができるReportBuilderクラスを持つことを検討してください。ReportBuilderを個別のクラスに分割できる場合は、これも行います。

はい。

複数の場所で機能を使用する必要があるコードセグメントがある場合。それ以外の場合、機能を変更する必要がある場合は、複数の場所で変更を行う必要があります。これは作業を増やすだけでなく、ある場所でコードが変更されて別の場所では変更されたり、ある場所で導入されても別の場所では導入されない場合にバグが発生するリスクを高めます。

また、説明的なメソッド名を使用すると、メソッドが読みやすくなります。

関数を区別するために番号付けを使用するという事実は、複製またはクラスの処理が多すぎるという根本的な問題があることを示唆しています。大きな関数を多くの小さな関数に分割することは、重複をリファクタリングする際の有用なステップになる可能性がありますが、それが最後ではありません。たとえば、次の2つの関数を作成します。

processSection1HeaderData();
processSection2HeaderData();

セクションヘッダーの処理に使用されるコードに類似点はありませんか？違いをパラメーター化することで、両方の共通の関数を抽出できますか？

関数を論理的なサブ関数に分割することは、サブ関数が再利用されない場合でも役立ちます。それは、それを短く、理解しやすいブロックに分割します。ただし、n＃行だけでなく、論理ユニットで行う必要があります。分割方法はコードによって異なります。共通のテーマは同じオブジェクトに対するループ、条件、操作です。基本的に、個別のタスクとして説明できるものすべて。

それで、はい、それは良いスタイルです-これは奇妙に聞こえるかもしれませんが、記述の再利用が制限されていることを考えると、再利用の試みについて慎重に考えることをお勧めします。使用法は、偶然に同じではなく、本当に同一であることを確認してください。同じブロック内のすべてのケースを処理しようとすることが、最初の場所で大規模な不格好な機能になってしまうことがよくあります。

これは主に個人的な好みだと思います。もしあなたの関数が再利用されるとしたら（そしてもっと一般的で再利用可能なものにできないと確信していますか？）私は間違いなくそれらを分割すると言うでしょう。また、関数やメソッドには2〜3画面以上のコードを含めないことをお勧めします。そのため、大きな関数が何度も繰り返されると、コードを読みやすくして分割することができます。

これらのレポートの開発に使用しているテクノロジーについては言及しません。C＃を使用しているようです。あれは正しいですか？その場合、関数をより小さなものに分割したくない場合は、＃regionディレクティブを代替と見なすこともできます。