잘 문서화 된 코드의 중요성을 이해합니다. 그러나 자체 문서화 코드 의 중요성도 이해합니다 . 특정 기능을 시각적으로 쉽게 읽을 수있을수록 소프트웨어 유지 관리 중에 더 빠르게 이동할 수 있습니다.
그 말로, 나는 큰 기능을 다른 작은 기능으로 분리하고 싶습니다 . 그러나 나는 한 클래스가 하나의 공개 방법을 제공하기 위해 클래스 중 5 개 이상을 가질 수있는 시점까지 그렇게합니다. 이제 다섯 개의 개인 메소드에 다섯 개의 공개 메소드를 곱하면, 그 공개 메소드에 의해 한 번만 호출 될 약 25 개의 숨겨진 메소드를 얻게됩니다.
물론, 이제는 공개 메소드를 읽는 것이 더 쉽지만, 너무 많은 기능을 갖는 것은 나쁜 습관이라고 생각합니다.
[편집하다]
사람들은 왜 너무 많은 기능을 갖는 것이 나쁜 습관이라고 생각하는지 묻습니다.
간단한 대답 : 그것은 직감입니다.
내 생각은 소프트웨어 엔지니어링 경험에 의해 뒷받침되지는 않습니다. 저에게 "작가의 블록"을 주었지만 프로그래머에게는 불확실성입니다.
과거에는 개인 프로젝트 만 프로그래밍했습니다. 최근에 팀 기반 프로젝트로 넘어갔습니다. 이제 다른 사람들이 내 코드를 읽고 이해할 수 있도록하려고합니다.
무엇이 가독성을 향상 시킬지 잘 모르겠습니다. 한편으로는 하나의 큰 기능을 명료 한 이름을 가진 다른 작은 기능으로 분리하려고 생각했습니다. 그러나 저의 다른 측면은 그것이 단지 중복 적이라는 것입니다.
그래서 올바른 길을 고르기 위해 이것을 밝히도록 요구하고 있습니다.
[편집하다]
다음, 나는 방법의 두 가지 버전이 포함 된 수 내 문제를 해결합니다. 첫 번째 코드는 큰 코드 덩어리를 분리 하지 않음 으로써 문제를 해결합니다 . 두 번째 는 별개의 것입니다.
첫 번째 버전 :
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");
}
두 번째 버전 :
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");
}
위의 예에서 후자는 프로그램의 전체 런타임 동안 한 번만 사용되는 함수를 호출합니다.
참고 : 위의 코드는 일반화되었지만 내 문제와 동일합니다.
자, 여기 내 질문이 있습니다 : 어느 질문입니까? 첫 번째 또는 두 번째 중 하나를 선택합니까?