Clean Code를 위한 규칙 정리

• 전문가들의 조언

  • 나쁜 코드의 위험을 이해하지 못하는 관리자 말을 그대로 따르는 행동은 전문가 답지 못하다
  • 모듈 안에서는 코드 중복을 줄여라
  • 네이밍을 정확히 하라
  • 간단한 추상화를 고려하라
  • 테스트를 짜라

• 네이밍

  • 주석이 필요하다면 의도를 분명히 드러내지 못함을 의미한다
  • 소문자 o,l을 이용한 변수 네이밍을 조심해라 → 0과 1에 비슷해보인다
  • 불용어(큰 의미가 없는 단어)의 사용을 피하라
  • 인코딩을 피해라
    • 헝가리안식 표기법은 망했다 → 데이터 타입을 붙이는 표기법
    • 인터페이스와 클래스 중 차라리 클래스를 인코딩하라 → ex) AClassImplementation
  • 클래스는 명사, 명사구를 이용하여 작성하라

• 함수

  • 함수에서 들여쓰기 수준은 1,2단을 넘어서게 되면 가독성이 떨어진다
  • 함수는 추상화 수준이 한 단계인것 만을 수행해야 한다 → 한 가지 작업만 해야 한다
  • 위에서 아래의 함수로 내려 갈 때 추상화 수준이 하나 씩 내려가야 한다 → 구체화 되어야 한다
  • switch, if-else 구문은 한 함수에 한 단계만 허용해야 가독성이 좋다
  • 인수(argument)는 3개 이상은 주의 해서 사용한다
  • 부수 효과(넘어온 인수나 시스템 전역변수의 수정)을 일으키지 않도록 주의하라

• 코딩 컨벤션

  • 적절한 행 길이를 유지하라 → 사용자의 모니터를 넘어가는 길이는 좋지 않다
  • 위에서 아래로 코딩을 작성하라
  • 개념이 다르다면 빈 행으로 분리하라
  • 밀접한 개념은 한 파일에 속해야 한다 → protected 변수가 위험한 이유
  • 변수는 사용하는 위치에 최대한 가까이 선언한다
  • 인스턴스 변수는 클래스 맨 처음에 선언한다
  • 선언부가 길다면 클래스를 분해해야 할 지 모른다

• 추상화

  • 구현을 감추려면 추상화가 필요하다 → 변수의 private 화가 필요하다
  • 사용자가 구현을 모른 채 자료의 핵심을 조작할 수 있어야 한다
  • 절차적 코드 vs 객체지향 코드

• 자료구조와 객체의 장/단점을 이해하고 유연하게 사용해야 한다

  • 너무 당연한…

• 오류와 예외 처리

  • 오류 코드보다 예외를 사용하라
  • Checked Exception은 캡슐화를 깨버리므로 Unchecked Exception을 사용하라
  • 예외에 의미를 제공하라 → 의미 있는 메시지를 반드시 담아라
  • null은 전달하지도 받지도 리턴하지도 마라
    • Optional 을 이용하라

• 경계

  • 다른 인터페이스 또는 라이브러리를 사용하는데 생기는 경계(boundary)
  • 경계면에서 컬렉션의 인스턴스를 API의 인수로 넘기거나 반환 값으로 사용하지 마라
    • 1급 컬렉션을 이용하라
  • 어댑터 패턴을 이용하여 미리 경계 인터페이스를 작성하라

• 테스트

  • 함수 당 assert 문은 최소로 줄여라
  • 테스트 함수는 하나의 개념만 테스트 하라
  • 테스트 코드는 많이 , 깨끗하게, 다양하게 작성하라