[Clean Code] 2장 의미있는 이름

『Clean Code(클린 코드) 애자일 소프트웨어 장인 정신 - 로버트 C. 마틴』 을 읽고 요약한 내용입니다.

이름을 잘 짓는 간단한 규칙

의도를 분명히 밝혀라
- 변수(혹은 함수나 클래스)의 존재 이유는? 수행 기능은? 사용 방법은? 따로 주석이 필요하다면 의도를 분명히 드러내지 못했다는 말이다.
- 의도가 드러나는 이름을 사용하면 코드 이해와 변경이 쉬워진다.
- “문제는 코드의 단순성이 아니라 코드의 함축성이다. 다시 말해, 코드 맥락이 코드 자체에 명시적으로 드러나야 한다. 암암리에 독자가 정보를 안다고 독단하지말자”
그릇된 정보를 피하라
- 프로그래머는 코드에 그릇된 단서을 남겨서는 안 된다. 그릇된 단서는 코드 의미를 흐린다.
- 유사한 개념은 유사한 표기법을 사용한다. 이것도 정보다. 일관성이 떨어지는 표기법은 그릇된 정보다.
의미 있게 구분하라
- 컴파일러나 인터프리터만 통과하려는 생각으로 코드를 구현하면 문제를 일으킨다.
- 컴파일러를 통과할지라도 연속된 숫자를 덧붙이거나 불용어(noise word)를 추가하는 방식은 적절하지 못하다. 불용어는 중복이다.
  - Product 라는 클래스가 있을때, 다른 클래스를 ProductInfo 혹은 ProductData 로 짓는다면 개념을 구분하지 않은 채 이름만 달리한 것이다.
  - Customer 와 CustomerObject 라는 클래스의 차이는 이름만으로 알 수 없다.
- 읽는 사람이 차이를 알도록 이름을 지어라.
  - CustomerInfo 와 Customer, accountData 와 account 는 구분할 수 없다.
발음하기 쉬운 이름을 사용하라
검색하기 쉬운 이름을 사용하라
- 검색하기 쉬운 이름이 상수보다 좋다.
- 이름 길이는 범위 크기에 비례해야 한다.
  - 일주일의 평일 수를 5 라고 설정하는 것보다 WORK_DAYS_PER_WEEK 라고 하는 것이 검색하기 쉽다.
인코딩을 피하라
- 유형이나 범위정보까지 인코딩에 넣으면 그만큼 이름을 해독하기가 어려워 진다.
- 즉 인코딩한 이름은 발음하기 어려우며 오타가 나기 쉬우니 피하도록 하자.
인터페이스와 구현 클래스
- Interface class와 concrete class
- ShapeFactory - ShapeFactoryImp
자신의 기억력을 자랑하지 마라
- 독자가 코드를 읽으면서 변수 이름을 자신이 아는 이름으로 변환해야 한다면 그 변수 이름은 바람직하지 못하다.
  - 예를들어 루프문에서 반복 횟수를 관례적으로 한 글자로 사용한다고 해서 a, b, c 등을 사용하지 말자.
클래스 이름
- 클래스 이름과 객체 이름은 명사나 명사구가 적합하다.
  - 좋은 예 : Customer, WikiPage, Account, AddressParser
  - Manager, Processor, Data, Info 과 같은 단어는 피하고, 동사는 사용하지 않는다.
메서드 이름
- 메서드 이름은 동사나 동사구가 적합하다.
  - 좋은 예 : postPayment, deletePage, savw
  - 접근자(Accessor), 변경자(Mutator), 조건자(Predicate) 는 javabean 표준에 따라 get, set, is 붙인다.
- 생성자를 오버로드할 경우 정적 팩토리 메서드를 사용하고 해당 생성자를 private으로 선언한다.

// 위 코드가 아래 코드보다 좋다.
Complex fulcrumPoint = new Complex(23.0);  
Complex fulcrumPoint = Complex.FromRealNumber(23.0);

기발한 이름은 피하라
- 특정 시대의 유행어 등은 바람직하지 못하다.
- 의도를 분명하고 솔직하게 표현해야 한다.
한 개념에 한 단어를 사용하라
- 추상적인 개념 하나에 단어 하나를 선택해 이를 고수한다.
말장난을 하지마라
- 프로그래머는 코드를 최대한 이해하기 쉽게 짜야 한다.
- 집중적인 탐구가 필요한 코드가 아니라 대충 훑어봐도 이해할 코드 작성이 목표다.
- 의도를 밝힐 책임이 저자에게 있는 잡지 모델(모형)이 바람직하다
해법 영역에서 가져온 이름을 사용하라
- 코드를 읽는 사람도 프로그래머라는 사실을 명심한다. 그러므로 전산 용어, 알고리즘이름, 패턴이름, 수학용어 등을 사용해도 괜찮다.
- 모든 이름을 문제영역(domain)에서 가져오는 정책은 현명하지 못하다.
문제영역에서 가져온 이름을 사용하라
- 적절한 ‘프로그래머 용어’가 없다면 문제 영역에서 이름을 가져온다. 그러면 코드를 보수하는 프로그래머가 분야 전문가에게 물어 파악할 수 있다.
의미 있는 맥락을 추가하라.
- 클래스, 함수, 이름 공간에 넣어 맥락을 부여한다. 모든 방법이 실패하면 마지막 수단으로 접두어를 붙인다.
불필요한 맥락을 없애라
- 일반적으로는 짧은 이름이 긴 이름보다 좋다. 단, 의미가 분명한 경우에 한해서다.
- 이름에 불필요한 맥락을 추가하지 않도록 주의한다.
정리하면
- 우리는 문장이나 문단처럼 읽히는 코드 아니면(정보를 표시하는 최선의 방법이 항상 문장만은 아니므로) 적어도 표나 자료구조처럼 읽히는 코드를 짜는 데만 집중해야 마땅하다.

코드를 작성할때 가장 고민되는 순간중 하나가 변수명, 메소드명 등 이름을 짓는 순간이었던것 같다. Info, Data 와 같은 단어들로 얼버무렸던 지난날의 코드들이 생각나서 반성하게 된다. 이름을 지을 때는 처음에도 어려웠지만 지금도 고민되는 순간이 참 많다. 더 고민하는 시간이 필요하다.

“코드를 읽는 사람도 프로그래머다” 보다 분명한 의도를 갖도록 주의할 것을 명심하자.

티스토리툴바