함수

작게 만들어라

• 함수는 작을 수록 좋다

블록과 들여쓰기

• 조건문 및 반복문에 들어가는 블록은 한 줄이어야 한다.
• 중첩 구조가 생길 만큼 함수가 커져서는 안된다는 뜻
• 그래야 읽고 이해하기 쉬워진다.

한 가지만 해라

• 함수는 한 가지만 해야한다.
• 다른 표현이 아니라 의미 있는 이름으로 다른 함수를 추출할 수 있다면 그 함수는 여러 작업을 하는 함수다.

함수 당 추상화 수준은 하나로

• 함수가 한 가지 작업만 하려면 함수 내 모든 문장의 추상화 수준이 동일해야 한다.
• 한 함수 내에 추상화 수준을 섞으면 코드를 읽는 사람이 헷갈린다.
• 코드는 위에서 아래로 이야기처럼 읽혀야 좋다.
• 좋은 함수는 위에서 아래로 읽으면서 함수 추상화 수준이 한 단계씩 낮아진다.
• ex)TO 설정 페이지와 해제 페이지를 포함하려면,설정 페이지를 포함하고,테스트 페이지 내용을 포함하고,해제 페이지를 포함한다.
• ex)TO 설정 페이지를 포함하려면,슈트이면 슈트 설정 페이지를 포함한 후 일반 설정 페이지를 포함한다.
• ->함수 추상화단계를 폴더처럼 구성하라는 말!

Switch 문

• 작게 만들기 어렵다.
• 한 가지 작업만 하는 것도 어렵다.
• 저차원 클래스에 숨기고 절대로 반복하지 않는 방법은 존재한다

서술적인 이름을 사용하라

• 함수의 내용을 함축하는 서술적인 이름이 좋다.
• 이름 붙일 때는 일관성이 있는 것이 좋다.
• ex)includeSetupAndTearDownPages,includeSetupPages,includeSuiteSetupPage…

함수 인수

• 함수에서 인수 개수는 작을 수록 좋다.
• 인수가 많을 수록 테스트도 어려워진다.
• 출력 인수는 입력 인수보다 이해하기 어렵다.
• 변환 함수일 경우 인수는 출력보다 입력 인수가 좋다.

플래그 인수

• 플래그 인수는 추하다.
• 함수가 여러 개를 처리한다고 공표하는 셈.
• render(boolean isSuite)는 renderForSuite와 renderforSingleTest로 나누어져야 한다.

이항 함수

• 자연적인 순서가 없는 두 인수의 순서를 기억해야만 한다.
• 가능하면 단항 함수로 바꾸도록 해야 한다.
• ex)이항 함수를 두 개의 단항 함수로 쪼개어 같은 클래스 내에 포함

삼항 함수

• 읽을 떄 순서가 헷갈릴 수 있다.
• 인수가 너무 많아지는 경우 별도의 클래스를 만들어 개수를 줄일 수 있다.
• 가변 인수 함수를 취하는 함수도 사실상 이항 함수로 취급될 수 있다.

동사와 키워드

• 단항 함수는 함수와 인수가 동사/명사 쌍을 이뤄야 한다.
• ex)writeField(name)
• assertEquals(expected,actual)보다 assertExpectedEqualsActual(expected,actual)이 인수 순서를 기억할 필요가 없으므로 더 좋다.

부수 효과를 일으키지 마라

• 시간적인 결합 및 순서 종속성을 초래한다.
• 출력 인수를 피해라
• ex)appendFooter(StringBuffer report)보다 report.appendFooter()가 낫다.

명령과 조회를 분리하라

• 객체 상태를 변경하거나 정보를 반환하거나 둘 중 하나만 해야 한다.
• 읽고 해석하는데 어려워 혼란을 초래한다.

오류 코드보다 예외를 사용하라

• 예외를 사용하면 오류 처리 코드가 원래 코드에서 분리되므로 깔끔해진다.
• 오류를 처리하는 함수는 오류만 처리해야 마땅하다.
• 오류 코드 대신 예외를 사용하면 새 예외는 Exception 클래스에서 파생되므로 재컴파일/재배치 없이도 새 예외 클래스를 추가할 수 있다.

반복하지 마라

• 중복은  변경 시 많은 수정을 필요로 한다.

구조적 프로그래밍

• 모든 함수는 블록에 입구와 출구가 하나만 있어야 한다.
• break 및 continue, goto를 사용하면 안 된다.
• 위 원칙은 함수가 아주 클 떄만 상당한 이익을 제공한다.