의도를 분명히 밝혀라
좋은 이름을 지으려면 시간이 걸리지만, 좋은 이름으로 절약하는 시간이 훨씬 더 많다.
이름을 주의 깊게 살펴 더 나은 이름이 떠오르면 개선하자.
변수나 함수 그리고 클래스 이름은 다음과 같은 질문에 모두 답해야 한다.
- 존재 이유는 무엇인가?
- 수행 기능은 무엇인가?
- 사용 방법은 어떻게 되는가?
int d; // 경과 시간 (단위: 날짜)위의 변수 d는 아무런 의미도 드러나지 않는다. 측정하려는 값과 단위를 표현하는 이름이 필요하다.
int elapsedTimeInDays;
int daysSinceCreation;
int daysSinceModification;
int fileAgeInDays;다음의 코드 예시를 보자.
public List<int[]> getThem() {
List<int[]> list1 = new ArrayList<int[]>();
for(int[] x : theList)
if(x[0] == 4)
list1.add(x);
return list1;
}코드가 하는 일 자체는 어려운 것이 없지만, 맥락이 코드 자체에 명시적으로 드러나지 않는다.
위의 코드는 독자가 다음 정보를 안다고 가정한다.
1. theList에 들어있는 원소의 의미
2. theList의 0번째 값이 어째서 중요한가?
3. 값 4의 의미
4. 함수가 반환하는 리스트 list1을 어떻게 사용하는가?
public List<int[]> getFlaggedCells() {
List<int[]> flaggedCells = new ArrayList<int[]>();
for(int[] cell : gameBoard)
if(cell[STATUS_VALUE] == FLAGGED)
flaggedCells.add(cell);
return flaggedCells;
}그릇된 정보를 피하라
나름대로 널리 쓰이는 의미가 있는 단어를 다른 의미로 사용하면 안 된다.
유사한 개념은 유사한 표기법을 사용한다. 일관성이 떨어지는 표기법은 그릇된 정보이다.
가장 끔찍한 예시라면 소문자 L이나 대문자 O 변수.
소문자 L을 숫자 1과, 대문자 O를 숫자 0과 혼동하게 만들 수 있기 때문.
int a = l;
if( O == l )
a = 01;
else
l = 01;의미 있게 구분하라
컴파일러를 통과하더라도 연속된 숫자를 덧붙이거나 불용어를 추가하는 방식은 적절하지 못하다.
이름이 달라야 한다면 의미도 달라져야 한다.
예를 들어, Product라는 클래스가 있다면, 다른 클래스를 ProductInfo 혹은 ProductData라 부른다면 개념을 구분하지 않은 채 이름만 달리한 경우이다.
Info나 Data는 a, an, the와 마찬가지로 의미가 불분명한 불용어다.
a나 the 같은 접두어를 쓰지 마라는 소리는 아니다.
예를 들어, 모든 지역 변수는 a를 사용하고 모든 함수 인수는 the를 사용하는 방식이라면 사용해도 좋다.
읽는 사람이 차이를 알도록 이름을 지어라.
발음하기 쉬운 이름을 사용하라
사람들은 단어에 능숙하다. 우리 두뇌에서 상당 부분은 단어라는 개념만 전적으로 처리한다.
발음하기 어려운 이름은 토론하기도 어렵다. 발음하기 쉬운 이름은 중요하다.
프로그래밍은 사회 활동이니까.
검색하기 쉬운 이름을 사용하라
문자 하나를 사용하는 이름과 상수는 쉽게 눈에 띄지 않는다. 심지어 검색을 할 때에도 문제가 된다.
변수나 상수를 코드 여러 곳에서 사용한다면 검색하기 쉬운 이름이 바람직하다. 두 예제를 비교해보자.
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;
}위의 코드에서 sum은 별로 유용하진 않지만 최소한 검색이 가능하다.
이름을 의미 있게 지으면 함수가 길어지지만, WORK_DAYS_PER_WEEK를 찾기가 얼마나 쉬운지 생각해보자.
인코딩을 피하라
유형이나 범위 정보까지 인코딩에 넣으면 그만큼 이름을 해독하기 어려워진다.
헝가리식 표기법
당시 컴파일러가 타입을 점검하지 않았으므로 프로그래머에게 타입을 기억할 단서가 필요했다.
PhoneNumber phoneString;하지만 이제는 코드를 컴파일하지 않고도 타입 오류를 감지할 정도로 발전했으니 이러한 헝가리식 표기법이나 기타 인코딩 방식이 오히려 방해가 된다.
멤버 변수 접두어
이제는 멤버 변수에 m_라는 접두어를 붙일 필요도 없다.
멤버 변수를 다른 색상으로 표시하거나 눈에 띄게 보여주는 IDE를 사용하자.
인터페이스 클래스와 구현 클래스
도형을 생성하는 ABSTRACT FACTORY를 구현한다고 가정하자.
이 팩토리는 인터페이스 클래스이며, 구현은 구체 클래스에서 한다. 그렇다면 두 클래스 이름을 어떻게 지어야 하는가?
IShapeFactory와 ShapeFactory?
책의 저자는 인터페이스 클래스 이름과 구현 클래스 이름 중 하나를 인코딩해야 한다면 구현 클래스 이름을 택하는 쪽이었다. ShapeFactoryImp나 CShapeFactory
자신의 기억력을 자랑하지 마라
전문가 프로그래머는 명료함이 최고라는 사실을 이해한다.
전문가 프로그래머는 자신의 능력을 좋은 방향으로 사용해 남들이 이해하는 코드를 내놓는다.
클래스 이름
클래스 이름과 객체 이름은 명사나 명사구가 적합하다.
Manager, Processor, Data, Info 등과 같은 단어는 피하고, 동사는 사용하지 않는다.
메서드 이름
메서드 이름은 동사나 동사구가 적합하다.
postPayment, deletePage, save 등이 좋은 예다.
접근자, 변경자, 조건자는 javabean 표준에 따라 값 앞에 get, set, is를 붙인다.
String name = employee.getName();
customer.setName("mike");
if (paycheck.isPosted())...생성자를 overload할 때는 정적 팩토리 메서드를 사용한다.
메서드는 인수를 설명하는 이름을 사용한다.
Complex fulcrumPoint = new Complex(23.0);기발한 이름은 피하라
재미난 이름보다 명료한 이름을 선택하라.
특정 문화에서만 사용하는 농담은 피하는 편이 좋다. 의도를 분명하고 솔직하게 표현하라.
한 개념에 한 단어 사용하기
똑같은 메서드를 클래스마다 fetch, retrieve, get으로 제각각 부르면 혼란스럽다.
이름이 다르면 독자는 당연히 클래스도 다르고 타입도 다르리라 생각한다.
말장난을 하지 마라
한 단어를 두 가지 목적으로 사용하지 마라.
예를 들어, 지금까지 구현한 add 메서드는 모두가 기존 값 두 개를 더하거나 이어서 새로운 값을 만든다고 가정하자. 새로 작성하는 메서드는 집합에 값 하나를 추가한다.
이 메서드를 add라 불러도 괜찮을까?
기존 메서드와 맥락이 다르므로 다른 이름이 적당하다.
해법 영역에서 가져온 이름을 사용하라
코드를 읽는 사람도 프로그래머다.
그러므로 전산 용어, 알고리즘 이름, 패턴 이름, 수학 용어 등을 사용해도 괜찮다.
모든 이름을 도메인에서 가져오는 정책은 현명하지 못하다.
같은 개념을 다른 이름으로 이해하던 동료들이 매번 고객에게 의미를 물어야하기 때문이다.
문제 영역에서 가져온 이름을 사용하라
적절한 '프로그래머 용어'가 없다면 문제 영역에서 이름을 가져온다.
의미 있는 맥락을 추가하라
스스로 의미가 분명한 이름이 없지 않지만, 대다수의 이름은 그렇지 못하다.
그래서 클래스, 함수, 이름 공간에 넣어 맥락을 부여한다. 모든 방법이 실패하면 마지막으로 접두어를 붙인다.
불필요한 맥락을 없애라
일반적으로 짧은 이름이 긴 이름보다 좋다.
단, 의미가 분명한 경우에 한해서다. 이름에 불필요한 맥락을 추가하지 않도록 주의하자.
