よく文書化されたコードの重要性を理解しています。しかし、自己文書化コードの重要性も理解しています。特定の機能を視覚的に読みやすくするほど、ソフトウェアのメンテナンス中にすばやく移動できます。
とはいえ、私は大きな機能を他の小さな機能に分離するのが好きです。しかし、1つのパブリックメソッドを提供するためだけに、クラスが5つまで持つことができるようになります。ここで、5つのプライベートメソッドに5つのパブリックメソッドを掛けると、それらのパブリックメソッドによって1回だけ呼び出される可能性のある、25の隠しメソッドを取得できます。
確かに、これらのパブリックメソッドは読みやすくなりましたが、機能が多すぎるのは悪い習慣だと思わざるを得ません。
[編集]
人々は、なぜ機能が多すぎるのが悪い習慣だと思うのかと私に尋ねてきました。
簡単な答え：それは直感です。
私の信念は、少しの間、ソフトウェアエンジニアリングの経験に支えられていません。「ライターのブロック」を与えたのは、プログラマーにとってだけの不確実性です。
過去には、私は個人的なプロジェクトのみをプログラミングしてきました。チームベースのプロジェクトに移ったのはつい最近のことです。ここで、他の人がコードを読んで理解できるようにします。
何が読みやすさを改善するのか分かりませんでした。一方では、1つの大きな関数を、わかりやすい名前を持つ他の小さな関数に分離することを考えていました。しかし、それは単に冗長であると言っている私の側面がありました。
それで、正しい道を選ぶために自分自身を啓発するように私はこれを求めています。
[編集]
以下は、私がどのように2つのバージョンが含ま可能性が私の問題を解決します。最初のものは、コードの大きな塊を分離しないことでそれを解決します。2番目は別のことを行います。
最初のバージョン：
public static int Main()
{
// Displays the menu.
Console.WriteLine("Pick your option");
Console.Writeline("[1] Input and display a polynomial");
Console.WriteLine("[2] Add two polynomials");
Console.WriteLine("[3] Subtract two polynomials");
Console.WriteLine("[4] Differentiate two polynomials");
Console.WriteLine("[0] Quit");
}
2番目のバージョン：
public static int Main()
{
DisplayMenu();
}
private static void DisplayMenu()
{
Console.WriteLine("Pick your option");
Console.Writeline("[1] Input and display a polynomial");
Console.WriteLine("[2] Add two polynomials");
Console.WriteLine("[3] Subtract two polynomials");
Console.WriteLine("[4] Differentiate two polynomials");
Console.WriteLine("[0] Quit");
}
上記の例では、後者はプログラムのランタイム全体で一度だけ使用される関数を呼び出します。
注：上記のコードは一般化されていますが、私の問題と同じ性質のものです。
さて、ここに私の質問があります：どれですか？最初のものを選びますか、それとも2番目のものを選びますか？