함수를 만드는 규칙

함수는 그 언어에서 동사며, 클래스는 명사다.

• 시스템에서 발생하는 모든 동작을 설명하는 함수 계층
• 즉, 시스템이라는 이야기를 풀어가는 데 목표를 두어야 한다.

작게 만들어라

함수의 길이

• 함수는 2~4줄 정도가 좋다.
  • 최대 100줄은 넘어서면 안된다.

블록과 들여쓰기

• If-else문, while 문 등에 들어가는 블록은 한 줄이어야 한다.
  • 이 안에서 대개 함수를 호출한다.
  • 그러면 바깥은 감싸는 함수가 작아지고, 코드를 이해하기 쉬워진다.
  • 다시 말해, 중첩 구조가 생길 만큼 함수가 커져서는 안 된다.
• 함수의 들여쓰기 수준은 1단이나 2단을 넘어서면 안 된다.

Switch문을 숨겨라

• switch문은 본질적으로 N가지를 처리한다.
• switch문을 완전히 피할 방법이 없으므로, 각 switch 문을 저차원 클래스에 숨기고 절대로 반복하지 않는다.
  • 다형성을 이용한다.
  • 예를 들어, 추상 팩토리에 switch문을 숨긴다.
• 물론 불가피한 상황도 생길 수 있다.

함수는 ‘한 가지’만 해야 한다.

함수는 한 가지를 해야 한다. 그 한 가지를 잘 해야 한다. 그 한 가지만을 해야 한다.

함수의 ‘한 가지’

• 단순히 다른 표현이 아니라 의미 있는 이름으로 다른 함수를 추출할 수 있다면 그 함수는 여러 작업을 하는 것이다.
• 함수 내 모든 문장의 추상화 수준은 동일해야 한다.

내려가기 규칙

• 코드는 위에서 아래로 이야기처럼 읽혀야 좋다.
• 한 함수 다음에는 추상화 수준이 한 단계 낮은 함수가 온다.
  • 즉, 위에서 아래로 읽으면 함수 추상화 수준이 한 번에 한 단계씩 낮아진다.

서술적인 이름을 사용하기

코드를 읽으면서 짐작했던 기능을 각 루틴이 그대로 수행한다면 깨끗한 코드라 불러도 되겠다.

서술적인 이름

• 이름은 함수가 하는 일을 좀 더 잘 표현해야 한다.
• 함수가 작고 단순할수록 서술적인 이름을 고르기 쉽다.
• 길고 서술적인 이름이 짧고 어려운 이름보다 좋다.

함수 이름을 정하는 방법

• 여러 단어가 쉽게 읽히는 명명법을 사용한다.
• 그 다음, 여러 단어를 사용해 함수 기능을 잘 표현하는 이름을 선택한다.
• 일관성 있는 이름을 붙여야 한다.
  • 모듈 내에서 함수 이름은 같은 문구, 명사, 동사를 사용한다.

함수 인수

함수의 인수 개수는 적어야 한다.

• 함수에서 이상적인 인수 개수는 0개(무항)이다.
• 그 다음은 1개(단항)이고, 다음은 2개(이항)이다.
• 3개(삼항)은 가능한 피해야 한다.
• 4항(다항)은 특별한 이유가 필요하고, 이유가 있어도 사용하면 안 된다.

단항 함수

• 인수에 질문을 던지는 경우
  • ex) boolean fileExists(”fileName”);
• 인수를 뭔가로 변환해 결과를 반환하는 경우
  • ex) InputStream fileOpen(”fileName”);
• 함수 이름을 지을 때, 두 경우를 분명히 구분하고 일관적인 방식으로 두 형식을 사용해야 한다.
• 드물게 사용하지만, 이벤트 함수일 경우에 사용하기도 한다.
  • 출력 인수는 없다.
  • 이벤트라는 사실이 코드에 명확히 드러나야 한다.
• 위 경우가 아니라면 단항 함수는 가급적 피해야 한다.
  • void includeSetupPageInfo(StringBuffer pageText) 와 같이 변환 함수에서 출력 인수를 사용하면 혼란을 일으킨다.
  • 입력 인수를 변환하는 함수는 변환 결과는 반환 값으로 돌려주어야 한다.

이항 함수

• 인수가 2개인 함수는 1개인 함수보다 이해하기 어렵다.
• 직교 좌표계와 같이 이항 함수가 적절한 경우도 있다.
• 가능하면 단항 함수로 바꾸도록 애써야 한다.

삼항 함수

• 순서, 주춤, 무시로 야기되는 문제가 두 배 이상 늘어난다.
  • EX) 매번 함수를 볼 때마다 주춤했다가, 어떤 인수를 무시해야 한다는 사실을 상기한다.
• 따라서 삼항 함수를 만들 때는 신중히 고려해야 한다.

플래그 인수는 사용하지 말자!

• 함수로 bool 값을 넘긴다는 건 함수가 한 번에 여러 가지를 처리한다고 공표하는 셈이다.
  • bool 값이 참이면 A 로직을 실행하고, 거짓이면 B 로직을 실행한다.
• 함수를 분리해서 사용하라.

인수 목록

• 가변 인수를 취하는 모든 함수에 같은 원리가 적용된다.
• 가변 인수를 취하는 함수는 단항, 이항, 삼항 함수로 취급할 수 있다.
• 하지만 이를 넘어서는 인수를 사용할 경우에는 문제가 있다.

인수가 여러 개 필요할 경우 대안

• 인수가 여러 개 필요하다면, 일부를 독자적인 클래스 변수로 선언할 가능성을 짚어 본다
  • ex) Circle makeCircle(double x, double y, double radius); → Circle makeCircle(Point center, double radius);

부수 효과를 일으키지 마라

여기서 말하는 부수 효과(Side effect)는 한 가지 일을 해야 할 함수 내부에서 다른 일을 처리하는 것을 말하는 듯 하다.

부수 효과

• 부수 효과는 시간적인 결합(temporal coupling)이나 순서 종속성(order dependency)를 초래한다.
• 만약 시간적인 결합이 필요하다면 함수 이름에 분명히 명시한다.
  • 함수가 ‘한 가지’만 한다는 규칙을 위반하게 되지만.

출력 인수

• 일반적으로 인수를 함수 입력으로 해석한다.
• 객체 지향 언어에서는 출력 인수를 사용할 필요가 없다.
  • 출력 인수로 사용하라고 설계한 변수가 바로 this 이다.
  • ex) appendFooter(report) → report.appendFooter()

명령과 조회를 분리하라

명령 함수와 조회 함수

• 함수는 뭔가를 수행하거나 뭐가에 답하거나 둘 중 하나만 해야 한다.
  • 객체 상태를 변경하거나, 객체 정보를 반환하거나

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

• 명령 함수에서 오류 코드를 반환하는 방식은 명령/조회 분리 규칙을 미묘하게 위반한다.
  • if 문에서 명령을 표현식으로 사용하기 쉽다. 그러면 동사/형용사 혼란을 일으키지 않는 대신 여러 단계로 중첩되는 코드를 야기한다.
  • ex) if (deletePage(page) == E_OK)
• 오류 코드를 반환하면 호출자는 오류 코드를 곧바로 처리해야 한다는 문제에 부딪힌다.
• 오류 코드를 사용하면 재컴파일/재배치가 번거롭다.
  • 의존성 자석(magnet)
  • 어디선가 오류 코드를 정의해야 하는데, 다른 클래스에서 오류 코드 클래스를 import해 사용해야 하므로 오류 코드가 변경되면 해당 클래스를 사용하는 클래스 전부를 다시 컴파일하고 다시 배치해야 한다.
• 따라서, 오류 코드 대신 예외를 사용해야 한다.
• Try/Catch 블록은 별도 함수로 뽑아내야 한다.
  • 코드 구조에 혼란을 일으키며, 정상 동작과 오류 처리 동작을 뒤섞기 때문이다.
• 오류 처리도 ‘한 가지’ 작업이다.
  • 오류를 처리하는 함수는 오류만 처리해야 한다.

반복하지 마라

• 중복을 제거 해야 한다.

구조적 프로그래밍 원칙

• 모든 함수와 함수 내 모든 블록에 입구와 출구가 하나만 존재해야 한다.
  • 즉, 함수는 return 문이 하나여야 한다.
  • 루프 안에서 break나 continue를 사용하면 안 되며 goto는 절대로 사용하면 안 된다.
• 그러나, 함수를 작게 만들면 간혹 return, break, continue를 여러 차례 사용해도 괜찮다.

Reference

참고 서적

📔 Clean Code