코드를 깨끗하게! Clean Code 팁

Clean Code

1. 깨끗한 코드

의도를 분명하게 이름을 지으라.

• 나쁜 예

    int d;

• 좋은 예

    int elapsedTimeDate;
    int daysSinceCreation;

  • 코드의 맥락이 코드 자체에 명시적으로 드러나게 하여 정보를 충분히 제공해야한다.

그릇된 정보를 피하자

• 일관성을 유지하여 깔끔한 정보를 주자.
• 미리 정해진 예약어는 피해서 깔끔한 정보를 주자.
• l과 1, o와 0과 같이 헷갈릴 수 있는 문자를 피하자.

불용어를 쓰지 말자.

• class라는 이름을 이미 사용하고 있어서 klass라고 하고싶은가? 하지말자.
• 불용어는 중복이기도 하다. money와 moneyObject가 있다면 무엇을 뒤져야 하는지 헷갈리지않겠는가! 쓰지말자.

발음하기 쉬운 이름을 사용하자.

• 프로그래밍은 사회활동이다. adfkv처럼 약어를 사용하지 말고 명시적인 이름을 사용하자.

검색하기 쉬운 이름을 사용하자.

• 숫자, 단어하나로만 이루어진 이름은 의미를 알 수도,
  검색하기도 힘들 것이다.

• 의미를 담아서 상수보단 단어를, 짧은 것보단 긴 의미있는 단어를 사용하자.

• 나쁜 예

        for(int j=0; j<34; j++;){
            s += (t[j]*4)/5;
        }

• 좋은 예
  ```java

    int realDaysPerIdealDay = 4;
    const int WORK_DAYS_PER_WEEK = 5;
    int sum = 0;
    for(int j=0; j < NUMBER_OF_TASKS; j++;){
        int realTaskDays = taskEstimate[j] * realDaysPerIdealDay;
        int realTaskWeeks = (realTaskDays / WORK_DAYS_PER_WEEK);
        sum += realTaskWeeks;
    }
     ```

  인코딩언어를 피하자.

• 클래스와 함수는 접두어가 필요없을 정도로 작아야 마땅하니 접두어를 남발하지말자.

• 인터페이스에 I라는 접두어는 자제하자.

  • I 접두사는 주의를 흐트리고 과도한 정보를 제공한다.
  • 인터페이스에 대한 정보를 알리지 않기위해 구현 클래스의 이름 뒤에 Imp를 붙이는게 낫다.

클래스 이름은?

• 클래스나 객체의 이름은 명쾌한 명사나 명사구가 적합하다.
• 좋은 예 : Customer, Account, AddressParser 등등..
• 나쁜 예 : Info, Data, Manager, Processor 등등..

메서드 이름은?

• 메서드 이름은 동사나 동사구가 적합하다.
• 접근자, 변경자, 조건자는 set,get, is를 사용한다.
• 좋은 예: save, deletePage,setName,isPosted 등등..
• 생성자를 오버로드 할 경우 new를 상요하자.

한 개념에 한 단어를!

• 똑같은 메서드를 클래스마다 제각각 부르지 말고 일관성있게 사용하자.

의미 있는 맥락을 추가하라

• 변수가 모여있으면 의미를 유추하겠지만 달랑 떨어져버리면 의미를 유추하기 어렵다
  • state -> addrState
• 한 클래스에 모아놓아서 맥락을 함께하면 의미를 유추하기 쉽고 더해서 함수를 쪼개기가 쉬워지기 때문에 알고리즘도 명확해진다.

불필요한 맥락을 없애라

• 짧은 이름보단 긴 이름이 좋다고 해서 모든 클래스에 해당 의미를 가진 이름을 다 박아넣는 것은 안 좋다.
• 의미가 분명하게만 하자.

2. 함수

함수는 작게 만들자!

• 중첩 구조가 생길만큼 함수가 커져서는 이해하기 힘들어진다.
• 최대한 작게!
• if / esle / while 문 등에 들어가는 블록은 한 줄로!

한 가지만 하자!

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

추상화 수준은 일정하게!

• 한 함수 내에 추상화 수준을 섞으면 코드를 읽는 사람이 헷갈린다.
• 위에서 아래로 갈 때 추상화 수준이 한 단계씩 낮아지게 하자. 위는 핵심이 되고 아래로 갈 수록 설명이 될 것이다.

Switch 문을 작게 만들자

• Switch문을 피할 수 없다면 다형성을 이용하여 숨기자!
  • Interface를 하나 만들어서 그것을 구현하는 클래스에 switch문을 숨겨서 사용하자.

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

• 짧고 알기 힘든 이름보다는 길고 기능이 잘 표현된 이름이 좋다.

함수 인수는 최대한 적게

• 함수 인수의 이상적인 개수는 0개이다.
• 인수가 많을 수록 코드를 읽기 힘들다.
• 단항 형식(인수 1개)은 인수에 질문을 던지거나 혹은 인수를 뭔가로 변환해 결과를 반환하는 경우 혹은 이벤트 함수(출력 인수가 없으며 입력 인수로 시스템 상태를 바꾸는 함수)에만 사용하자.
• 플래그 인수는 추하다.
  • 함수가 여러 가지를 처리한다고 대놓고 공표하는 셈
• 인수가 2-3개 필요하다면 일부를 독자적인 클래스 변수로 선언해보자.

  Circle makeCircle(double x, double y, double radius);
  Circle makeCircle(Point center, double radius);

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

• 함수에서 한 가지를 하겠다고 약속하고선 남몰래 다른 짓을 하지마라. 위험하다!

명령과 조회를 분리하라!

• 함수는 수행하거나 답하거나 하나만 해야 한다.
• 둘 다 하는 함수는 빨리 분리해버리자.

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

• 오류 코드도 '한 가지'의 작업이다. 함수는 하나만 해야한다. 오류 코드를 따로 분리해버리자.
• Try/Catch 블록도 마찬가지! 별도로 뽑아버리자.

이 모든걸 지킬 수 있는지?

• 한 번에 지킬 수 없을 것이다. 단위 테스트 케이스를 만들고 코드를 다듬고 함수를 만들고 이름을 바꾸고 중복을 제거하자.

4. 객체와 자료구조

객체코드 vs 자료구조 코드

• 객체
  • get set 등의 조회 함수를 설정하면서 구현을 외부로 노출하면 안된다.
  • 구현을 모른 채 자료의 핵심을 조작할 수 있어야 진정한 의미의 클래스이다.
  • 함수는 공개하며 자료는 숨겨버린다(추상화).
  • 뭔가를 하라고 해야지 속을 드러내라고 하면 안 된다.
• 자료구조
  • 자료를 공개하며 함수는 제공하지않는다.
• 객체 vs 자료구조
  • (자료구조를 사용하는)절차적인 코드는 기존 자료구조를 변경하지 않으면서 새 함수를 추가하기 쉬운 반면, 객체 지향 코드는 기존 함수를 변경하지 않으면서 새 클래스를 추가하기 쉽다.
  • 둘은 상반된 개념이다.
• 결론
  • 둘은 상반된 관계이니 어중간하게 둘을 섞지말고 자료구조면 자료구조의 역할을(자료노출), 객체라면 객체의 역할(자료 비노출)을 하게 하자.
  • 자료타입을 추가하는 유연성이 필요할 때 객체사용
  • 동작을 추가하는 유연성이 필요할 때 자료구조 와 절차적인 코드사용

---

참고문헌
Clean Code 애자일 소프트웨어 장인 정신 : 로버트 C.마틴 지음