2장 - 의미 있는 이름

이름 잘 짓는 규칙

의도 분명히 밝히기

따로 주석이 필요 없을 정도로

• 변수의 존재 이유
• 수행 기능
• 사용 방법

그릇된 정보 피하기

• 널리 쓰이는 의미가 있는 단어를 다른 의미로 사용하면 안됨
  - hp, aix, sco (유닉스 플랫폼이나 변종 가리키는 이름이라 사용하면 안됨)
• 실제 List가 아니면 accountList라고 명명하지 않음
  - 계정 담는 컨테이너가 실제 List가 아니면 안됨
  - accountGroup, bunchOfAccounts, Accounts 라 명명할 것
  - 실제 컨테이너가 List라도 컨테이너 유형을 이름에 안 넣는게 좋음
• 서로 흡사한 이름 사용하면 안됨
• 유사한 개념은 유사한 표기법 사용할 것
  일관성 떨어지는 표기법은 그릇된 정보임

의미 있게 구분하기

• 컴파일러나 인터프리터만 통과하려고 하지 말기
  - 동일한 범위 안에서 다른 두 개념에 같은 이름 사용하지 못할 때, 한쪽 이름을 마음대로 바꾸지 말기
• 컴파일러를 통과해도 연속된 숫자 덧붙이거나 불용어 추가하지 않기
  - 이름 달라야 하면 의미도 달라야 함
  - a1, a2, a3, ... -> 아무 의미가 없음
  - ProductInfo, ProductData -> 개념 구분하지 않고 이름만 다르게 한 경우
  - 모든 지역변수는 a, 모든 함수 인수는 the 를 사용하는 식으로 접두어 사용할 것
    (zork 변수가 있다는 이유만으로 theZork라 명명하지 말것
• 불용어는 중복임
  - 변수 이름에 variable과 같은 단어는 금물 (표 이름에 table도 금지)
    Name과 NameString은 같은 의미
• 읽는 사람이 차이를 알도록 이름 지을 것

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

• 발음하기 어려운 이름은 토론하기도 어려움
  - genymdhms (generate date, year, month, day, hour, minute, second)

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

• 문자 하나만 사용하거나 상수 이름은 텍스트 코드에서 쉽게 찾을 수 없음
• 긴 이름이 짧은 이름보다 좋음 (검색하기 쉬운 이름이 상수보다 좋음)
• 간단한 메서드에서 로컬 변수만 한 문자를 사용
• 이름 길이는 범위 크기에 비례해야 함

인코딩 피하기

• 이름에 인코딩 할 정보는 많음
• 유형이나 범위 정보까지 인코딩에 넣으면 해독하기 어려워짐
• 인터페이스 클래스와 구현 클래스
  - 인터페이스 이름은 접두어 안 붙이는게 좋음 (개인적 견해)
  - 내가 다루는 클래스가 인터페이스라는 사실을 알리고 싶지 않음 (개인적)
  - ShapeFactoryImp나 CShapeFactory가 IShapeFactory보다 좋음
  
  

기억력을 자랑하지 말기

• 독자가 코드를 읽으면서 변수 이름을 자신이 아는 이름으로 변환해야 하면 안됨
  - 문제 영역, 해법 영역에서 일반적으로 사용하지 않는 이름 선택해서 생기는 문제
• 문자 하나만 사용하는 변수 이름은 안됨 (반복문에서 사용하는 i,j,k는 ㄱㅊ)
• 명료함이 최고

클래스, 메서드 이름

• 클래스, 객체 이름은 명사/명사구가 좋음
  - Customer, WikiPage, Account 등
  - Manager, Processor, Data, Info 와 같은 단어 피하기
  - 동사는 쓰지 않기
• 메서드 이름은 동사/동사구가 좋음
  - postPayment, deletePage, save
  - 접근자, 변경자, 조건자는 javabean 표준에 따라 값 앞에 get, set, is를 붙임
  - 생성자를 중복정의 할 때 (Constructor overload) 정적 팩토리 메서드 사용
    메서드는 인수 설명하는 이름 사용
    생성자 사용 제한하려면 생성자를 private로 선언하기

기발한 이름 피하기

• 재밌는 이름보다 명료한 이름 선택할 것
• 의도를 솔직하고 분명하게 표현하기

하나의 개념에 하나의 단어 사용하기

• 추상적인 개념 하나에 단어 하나를 선택해서 고수하기
  - 똑같은 메서드를 클래스마다 fetch, retrieve, get으로 다르게 부르면 혼란스러움
• 메서드 이름은 독자적이고 일관적이어야 함
• 동일 코드에 controller, manager, driver를 섞어 쓰지 말기
• 일관성 있는 어휘 사용하기

말장난 금지

• 한 단어를 두 가지 목적으로 사용하지 말기
• 같은 맥락이 아닐 때 일관성 고려해서 같은 단어 선택하지 않기
  - 지금까지 구현한 add는 기존 값 2개 더하기, 이어서 새로운 값 만들기일 때
    새로 작성하는 메서드는 집합에 값 하나 추가하는 것
    이런 상황에서는 insert, append가 적당함
• 대충 훑어봐도 이해할 코드 작성이 목표임

해법 영역에서 가져온 이름 사용하기

• 전산 용어, 알고리즘 이름, 패턴 이름, 수학 용어 사용해도 ㄱㅊ
• 기술 개념에는 기술 이름이 가장 적합한 선택임

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

• 적절한 '프로그래머 용어' 없을 때 문제 영역에서 이름 가져오기
• 해법 영역과 문제 영역 구분할 줄 알아야 함
• 문제 영역과 관련 깊은 코드라면 거기서 이름 따와야 함

의미 있는 맥락 추가하기

• 클래스, 함수, 이름 공간에 의미를 넣어 맥락 부여하기 (마지막 수단은 접두어)
  - firstName, lastName, street, city 보다는 addrFirstName, addrLastName, addrStreet, addrCity
  - Address 클래스 생성하면 더 좋음

불필요한 맥락 없애기

• 일반적으로 짧은 이름이 긴 이름보다 좋음 (의미가 분명한 경우에 한해서)
  - accountAddress, customerAddress는 Address 클래스 인스턴스로는 좋은 이름
  - 클래스 이름으로는 부적합함 (Address는 클래스 이름으로는 적합함)
  - 포트 주소, MAC 주소, 웹 주소 구분해야 하면 (PostalAddress, MAC, URI도 ㄱㅊ)