[Clean Code] 3. 함수

0

Clean Code

목록 보기
3/7
post-thumbnail

[Clean Code] 3. 함수

작게 만들어라

  • 함수는 짧을수록 좋다!
    • if 문/else문/while문 등에 들어가는 블록은 한 줄이어야 한다
    • 중첩 구조가 생기면 안된다 -> 들여쓰기가 1단이나 2단을 넘으면 안된다

한 가지만 해라

  • 함수는 한 가지만 해야한다
  • 함수 내 섹션을 나눌 수 있다면, 한 함수에서 여러 작업을 한다는 의미

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

  • 함수 내 모든 문장의 추상화 수준이 동일해야
  • 내려가기 규칙:
    • 코드는 위에서 아래로 읽혀야한다
    • 한 함수 다음에는 추상화 수준이 한 단계 낮은 함수가 온다

Switch 문

  • switch문은 작게 만들기 어렵다
    -> 본질적으로 switch문은 N가지를 처리한다
  • switch문을 저차원 클래스에 숨기고 절대 반복하지 않는 방법: 다형성(polymorphism)
    • ex. 직원 유형에 따라 switch문으로 다른 함수를 호출해야하는 경우
      -> switch문을 추상 팩토리 클래스에 숨긴다
      -> 팩토리는 switch문을 이용해 적절한 Employee 파생 클래스의 인스턴스를 생성한다
      -> Employee 인터페이스를 거쳐 함수를 호출한다
      -> 다형성으로 인해 실제 파생 클래스의 함수가 실행된다

서술적인 이름을 사용하라!

  • 길고 서술적인 이름이 짧고 어려운 이름보다 낫다
  • 길고 서술적인 이름이 길고 서술적인 주석보다 낫다

함수 인수

  • 함수에서 인수 개수는 적을수록 좋다
    • 0개 사용하는 것이 최선이다
    • 4개 이상은 사용하면 안된다!
  • 일반적으로 우리는 인수를 함수 입력으로 해석
    -> 출력 인수 사용 X

  • 많이 쓰는 단항 함수
    (1) 인수에 질문을 던지는 경우
    (2) 인수를 변환해 결과를 반환하는 경우
    (3) 이벤트 함수

    • 입력 인수만 있고 출력 인수가 없다
    • 입력 인수로 시스템 상태를 바꾼다
  • 위 경우가 아니라면, 단항 함수는 가급적 피한다

  • 플래그 인수: 함수로 부울 값을 넘기는 것은 추하다!
    -> true일 때 호출될 함수, false일 때 호출될 함수로 나누기
  • 이항 함수/삼항 함수:
    • 인수의 순서를 인위적으로 기억해야함 -> 실수할 위험
    • 가능하면 단항 함수로 바꾸어야
  • 인수 객체
    • 인수 2~3개가 필요하다면 -> 독자적인 클래스 변수로 선언하기
  • 인수 목록
    • 인수 개수가 가변적인 함수 -> List형 인수 하나로 취급
  • 좋은 함수 이름
    • 함수와 인수가 동사-명사 쌍을 이루기
      ex. writeField(name)
    • 함수 이름에 인수 이름 넣기 -> 인수 순서 기억할 필요 X
      ex. assertExpectedEqualsActual(expected, actual)

부수 효과를 일으키지 마라!

  • 시간적인 결합(temporal coupling) 초래
    -> 특정 상황에서만 호출 가능
  • 순서 종속성(order dependency) 초래

명령과 조회를 분리하라!

  • 객체 상태를 변경하거나, 객체 정보를 반환하거나 둘 중 하나만 해야한다

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

  • 명령 함수에서 오류 코드를 반환하는 형식 -> 명령/조회 분리 규칙 위반
  • Error.java 의존성 자석
    • 오류 코드를 반환한다는 것 = 어디선가 오류 코드를 정의한다는 뜻(ex. enum class)
    • 다른 클래스에서 오류 코드를 import해서 사용
      -> 오류 코드 클래스가 변한다면, 오류 코드를 사용하는 클래서 전부 변경해야
  • 오류 코드 대신 예외(try-catch) 사용하기
    -> try-catch 블록을 별도 함수로 뽑아내기
    -> try 블록에서 수행될 정상 동작 함수, catch 블록에서 수행될 오류 처리 동작 함수로 분리

반복하지 마라!

구조적 프로그래밍

  • 애츠허르 데이크스트라(Edsger Dijkstra)의 구조적 프로그래밍 원칙:
    모든 함수와 모든 함수 내 모든 블록은 entry와 sxit이 하나만 존재해야
    • 루프 내 break나 continue 사용 X
    • goto 사용 X
  • 위 원칙은 함수가 아주 클 때만 이익 제공
profile
Be able to be vulnerable, in search of truth

0개의 댓글