의도를 분명히 밝혀라
- 변수, 함수, 클래스의 이름이 포함하고 있어야 할 정보
- 예시
- int d; bad
- int daysSinceCreation; good
그릇된 정보를 피하라
- 목록을 불러오더라도 List 자료형을 사용하는 것이 아니면 이름에 List를 포함시키지 말 것
- 목록을 List를 이용해 담아오더라도 이름에 List는 안 쓰는게 좋음
- 흡사한 이름 쓰지 말 것
- XYZControllerForEfficientHandlingOfStrings
- XYZControllerForEfficientStorageOfStrings
- ‘소문자 L, 대문자 O’
- ‘l’은 숫자 1과 헷갈리고 O는 숫자 0과 헷갈림
의미 있게 구분하라
- 컴파일러/인터프리터만 통과하면 된다는 식으로 작명 X
- 연속적인 숫자를 덧붙이지 말 것
- String a1
- String a2
- String a3 …
- 불용어(noise word)를 추가하지 말 것
- getActiveAccount();
- getActiveAccounts();
- getActiveAccountInfo();
발음하기 쉬운 이름을 사용하라
// 나쁜 예
class DtaRcrd102 {
private Date genymdhms;
private Date modymdhms;
private final String pszqint = "102";
/* ... */
};
// 좋은 예
class Customer {
private Date generationTimestamp;
private Date modificationTimestamp;
private final String recordId = "102";
/* ... */
};
검색하기 쉬운 이름을 사용하라
// 나쁜 예
for (int j=0; j<34; j++) {
s += (t[j]*4)/5;
}
// 좋은 예
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;
}
- grep으로 찾기 쉬우려면 긴 이름이 짧은 이름보다 좋다.
- 이름 길이는 scope 크기에 비례해야 한다. 간단한 메서드의 로컬 변수에서만 한 문자를 사용
인코딩을 피하라
- 자바 프로그래머는 변수 이름에 타입을 인코딩할 필요가 없다.
- PhoneString phoneString → PhoneNumber phoneString; // 타입이 바뀌어도 이름은 바뀌지 않는다!
- 인터페이스 클래스와 구현 클래스
- IShapeFactory - ShapeFactory Bad
- ShapeFactory - ShapeFactoryImp / CShapeFactory / IShapeFactory Good
자신의 기억력을 자랑하지 마라
- 독자가 코드를 읽으면서 변수 이름을 자신이 아는 이름으로 변환해야 한다면 그 변수 이름은 바람직하지 못하다.
클래스 이름
- 클래스 이름과 객체 이름은 명사나 명사구가 적합하다.
- Customer, WikiPage, Account, AddressParser good
- Manager, Processor, Data, Info bad
- 동사 bad
메서드 이름
- 메서드 이름은 동사나 동사구가 적합하다.
- postPayment, deletePage, wave good
- 접근자(Accessor), 변경자(Mutator), 조건자(Predicate)는 javabean 표준에 따라 앞에 get, set, is를 붙인다.
- 생성자를 중복정의(overload)할 때는 정적 팩토리 메서드를 사용한다.
- Complex fulcrumPoint = Complex. FromRealNumber(23.0); good
- Complex fulcrumPoint = new Complex(23.0); bad
기발한 이름은 피하라
- HolyHandGrenade → DeleteItems
- whack() → kill()
- eatMyShort() → Abort()
한 개념에 한 단어를 사용하라
- 똑같은 메서드를 클래스마다 fetch, retrieve, get으로 제각각 부르면 혼란스럽다.
한 단어를 두 가지 목적으로 사용하지 마라
해법 영역에서 가져온 이름을 사용하라
- 모든 이름을 문제 영역(domain)에서 가져오는 정책은 현명하지 못하다.
- 프로그래머에게 익숙한 기술 개념에는 기술 이름이 가장 적합한 선택이다.
문제 영역에서 가져온 이름을 사용하라
- 적절한 ‘프로그래밍 용어'가 없다면 문제 영역에서 이름을 가져온다.
의미 있는 맥락을 추가하라
- firstName, lastName, street, houseNumber, city, state, zipcode bad
- state만 따로 보면 주소 일부라는 사실을 알 기 힘듦.
- addrFirstName, addrLastName, … , addrState, addrZipcode good
불필요한 맥락을 없애라
- ‘고급 휘발유 충전소 Gas Station Deluxe’라는 애플리케이션을 짠다고, 모든 클래스 이름을 GSD로 시작하겠다는 생각은 바람직하지 못하다.
- 의미가 분명하다면 일반적으로 짧은 이름이 긴 이름보다 좋다.