클린 코드 (Clean Code) - 2장 의미 있는 이름

노션 정리

2장 의미 있는 이름

 

😃 책에서 기억하고 싶은 내용을 써보세요.

의도를 분명히 밝혀라

• 변수나 함수 그리고 클래스 이름은 다음과 같은 질문에 모두 답해야 한다. 따로 주석이 필요하다면 의도를 분명히 드러내지 못했다는 말이다.
  • 존재 이유는?
  • 수행 기능은?
  • 사용 방법은?

그릇된 정보를 피하라

• 나름대로 널리 쓰이는 의미가 있는 단어를 다른 의미로 사용하면 안 된다.
  • e.g. hp, aix, sco ⇒ 유닉스 플랫폼이나 유닉스 변종을 가리키는 이름
• 여러 계정으로 그룹을 묶을 때, 실제 List가 아니라면 accountList라 명명하지 않는다. → accountGroup, bunchOfAccounts, Accounts
• 서로 흡사한 이름을 사용하지 않도록 주의한다.
  • e.g. A 모듈에 XYZControllerForEfficientHandlingOfString B 모듈에 XYZControllerForEfficientStorageOfString
• 유사한 개념은 유사한 표기법을 사용한다. 일관성이 떨어지는 표기법은 그릇된 정보다.
• 이름으로 그릇된 정보
  • e.g. 소문자 L과 숫자 1 대문자 O과 숫자 0

의미 있게 구분하라

• 컴파일러를 통과할지라도 연속된 숫자를 덧붙이거나 불용어(noise word)를 추가하는 방식은 적절하지 못하다. 이름이 달라야 한다면 의미도 달라져야 한다.
  • e.g. Info, Data, variable, table 등
• 읽는 사람이 차이를 알도록 이름을 지어라.

발음하기 쉬운 이름을 사용하라

• 발음하기 어려운 이름은 토론하기도 어렵다.

검색하기 쉬운 이름을 사용하라

• 이름 길이는 범위 크기에 비례해야 한다.
• 변수와 상수를 코드 여러 곳에서 사용한다면 검색하기 쉬운 이름이 바람직하다.

인코딩을 피하라

• 헝가리안 표기법
  • 옛날에는 컴파일러가 타입을 점검하지 않았으므로 프로그래머가 타입을 기억할 단서가 필요했다. 하지만 요즘은 컴파일러가 타입을 기억하고 강제한다.
  • IDE는 코드를 컴파일하지 않고도 타입 오류를 감지할 정도로 발전했다. 따라서 헝가리식 표기법이나 기타 인코딩 방식이 오히려 방해가 될 뿐이다.
• 멤버 변수 접두어
  • 이제는 멤버 변수에 m_이라는 접두어를 붙일 필요도 없다. 클래스와 함수는 접두어가 필요없을 정도로 작아야 마땅하다.
• 인터페이스 클래스와 구현 클래스
  • 때로는 인코딩이 필요한 경우도 있다.
  • 인터페이스 이름은 접두어를 붙이지 않는 편이 좋다고 생각한다. 그래서 인터페이스 클래스 이름과 구현 클래스 이름 중 하나를 인코딩해야 한다면 구현 클래스 이름을 택하겠다.

자신의 기억력을 자랑하지 마라

• 독자가 코드를 읽으면서 변수 이름을 자신이 아는 이름으로 변환해야 한다면 그 변수 이름은 바람직하지 못하다.
• 문자 하나만 사용하는 변수 이름은 문제가 있다.
• 루프에서 반복 횟수를 세는 변수 i, j, k는 괜찮다. (소문자 L은 절대 안된다.) 단, 루프 범위가 아주 작고 다른 이름과 충돌하지 않을 때만 괜찮다.

클래스 이름

• 클래스 이름과 객체 이름은 명사나 명사구가 적합하다. e.g. Customer, WikiPage, Account, AddressParser 등
• Manager, Processor, Data, Info 등과 같은 단어는 피하고, 동사는 사용하지 않는다.

메서드 이름

• 동사구가 적합하다. e.g. postPayment, deletePage, save 등
• 접근자(Accessor), 변경자(Mutator), 조건자(Predicate)는 javabean 표준에 따라 값 앞에 get, set, is를 붙인다.
• 생성자(Constructor)를 중복정의(Overload)할 때는 정적 팩토리 메서드를 사용한다.
• 메서드는 인수를 설명하는 이름을 사용한다.

기발한 이름은 피하라

• 재미난 이름보다 명료한 이름을 선택하라.
• 의도를 분명하고 솔직하게 표현하라.

한 개념에 한 단어를 사용하라

• 추상적인 개념 하나에 단어 하나를 선택해 이를 고수한다.
• 똑같은 메서드를 클래스마다 fetch, retrieve, get으로 제각각 부르면 혼란스럽다.
• 일관성 있는 어휘는 코드를 사용할 프로그래머가 반갑게 여길 선물이다.

말장난을 하지 마라

• 한 단어를 두 가지 목적으로 사용하지 마라. 다른 개념에 같은 단어를 사용한다면 그것은 말장난에 불과하다.
• 프로그래머는 코드를 최대한 이해하기 쉽게 짜야 한다. 집중적인 탐구가 필요한 코드가 아니라 대충 훑어봐도 이해할 코드 작성이 목표다.
• 의미를 해독할 책임이 독자에게 있는 논문 모델이 아니라 의도를 밝힐 책임이 저자에게 있는 잡지 모델이 바람직하다.

해법 역역에서 가져온 이름을 사용하라

• 코드를 읽을 사람도 프로그래머라는 사실을 명심한다. 그러므로 전산 용어, 알고리즘 이름, 패턴 이름, 수학 용어 등을 사용해도 괜찮다.
• 모든 이름을 문제 영역에서 가져오는 정책은 현명하지 못하다.
• 기술 개념에는 기술 이름이 가장 적합한 선택이다.

문제 영역에서 가져온 이름을 사용하라

• 적절한 ‘프로그래머 용어’가 없다면 문제 영역에서 이름을 가져온다. 그러면 코드를 보수하는 프로그래머가 분야 전문가에게 의미를 물어 파악할 수 있다.
• 우수한 프로그래머와 설계자라면 해법 영역과 문제 영역을 구분할 줄 알아야 한다.
• 문제 영역 개념과 관련이 깊은 코드라면 문제 영역에서 이름을 가져와야 한다.

의미 있는 맥락을 추가하라

• 스스로 의미가 분명한 이름이 없지 않다. 하지만 대다수 이름은 그렇지 못하다. 그래서 클래스, 함수, 이름 공간에 넣어 맥락을 부여한다. 모든 방법이 실패하면 마지막 수단으로 접두어를 붙인다.
• e.g. fistName, lastName, street, houseNumber, city, state, zipcode는 주소라는 사실을 알 수 있다. 하지만 state만 사용한다면 주소 일부라는 걸 모른다. addr이라는 접두어를 쓰면 맥락이 좀 더 분명해지고 변수가 좀 더 큰 구조에 속한다는 사실을 적어도 독자에게는 분명해진다.

불필요한 맥락을 없애라

• 의미가 분명한 경우 일반적으로 짧은 이름이 긴 이름보다 좋다.
• 이름이 불필요한 맥락을 추가하지 않도록 주의한다.
• accountAddress와 customerAddress는 Address 클래스 인스턴스로는 좋은 이름이나 클래스 이름으로는 적합하지 못하다. Address는 클래스 이름으로 적합하다.

 

🤔 오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요

• 이름 짓는 게 가장 기초적이면서도 가장 많은 정보를 줄 수 있는 만큼 잘 지켜야한다.
• 이 규칙 하나로 내 코드를 읽는 게 더 쉬워졌다.