Clean Code #2 의미 있는 이름

피드백, 오타 지적 환영합니다

의도를 분명히 밝혀라

"의도가 분명하게 이름을 지으라" 고 말하기는 쉽다. 여기서는 의도가 분명한 이름이 정말로 중요하다는 사실을 거듭 강조한다.

좋은 이름을 지으려면 시간이 걸리지만 좋은 이름으로 절약하는 시간이 훨씬 더 많다.

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;
}

public List<int[]> getFlaggedCells(){
    List<int[]> flaggedCells = new ArrayList<int[]>();
	for(int[] cell : gameBoard)
        if (cell[STATUS_VALUE] == FLAGGED)
            list1.add(x);
	return list1;
}

위에서 보듯 코드의 단순성은 변하지 않았다. 연산자 수와 상수 수는 앞의 예와 똑같으며 들여쓰기 단계도 동일하다. 그런데도 코드는 더욱 명확해졌다.

그릇된 정보를 피하라

프로그래머는 코드에 그릇된 단서를 남겨서는 안 된다. 그릇된 단서는 코드의 의미를 흐린다. 나름대로 널리 쓰이는 의미가 있는 단어를 다른 의미로 사용해도 안된다. 예를 들어 hp, aix, sco는 변수 이름으로 적합하지 않다. 직각함각형의 빗변 Hypotenuse를 구현할 때는 hp가 훌륭한 약어로 보일지라도 hp라는 변수는 독자에게 그릇된 정보를 제공한다.

또한 실제 List가 아니라면 accountList라 명명하지 않는다. 그러므로 accountGroup, bunchOfAccounts, 아니면 단순히 Accounts라 명명한다.

서로 흡사한 이름도 이용하지 않도록 주의한다. 한 모듈에서 XYZControllerForEfficientHandlingOfStrings라는 이름을 사용하고 조금 떨어진 모듈에서 XYZControllerForEfficientStorageOfStrings라는 이름을 사용한다면? 차이를 알아챘는가?

XYZControllerForEfficientHandlingOfStrings, XYZControllerForEfficientStorageOfStrings

두 단어는 겁나게 비슷하다.

유사한 개념은 유사한 표기법을 사용한다. 이것도 정보다. 일관성이 떨어지는 표기법은 그릇된 정보다. 자동 완성 기능을사용할 때 후보 목록에 유사한 개념이 알파벳 순으로 나온다면 그리고 각 개념 차이가 명백히 드러난다면 코드 자동 완성기능은 굉장히 유용해진다.

이름으로 그릇된 정보를 제공하는 진짜 끔찍한 예가 소문자 L이나 대문자 O 변수다.

int a = 1;
if ( O == 1 )
    a = O1;
else
    l = 01;

어떤 경우는 글꼴을 바꿔 차이를 드러내는 해결책을 제안하지만 이름만 바꾸면 문제가 깨끗이 풀린다. 괜스레 일거리를 만들 필요가 없다.

의미있게 구분하라

컴파일러를 통과하더라도 연속된 숫자를 덧붙이거나 불용어(noise word)를 추가하는 방식은 적절하지 못하다.

public static void copyChars(char a1[], char a2[]){
    for(int i = 0; i < a1.length; i++)
        a2[i] = a1[i];
}

함수이름으로 source와 destination을 사용한다면 코드 읽기가 훨씬 더 쉬워진다.

불용어를 추가한 이름 역시 아무런 정보를 제공하지 못한다. Product라는 클래스가 있다고 가정하다. 다른 클래스를 ProductInfo 혹은 ProductData라 부른다면 개념을 구분하지 않은 채 이름만 달리한 경우다. Info 나 Data 는 a, an, the 와 마찬가지로 의미가 불분명한 불용어다.

a와 the를 사용하지 말라는 소리가 아니다. 예를 들어 모든 지역변수는 a를 사용하고 모든 함수 인수는 the를 사용하는 것ㄹ처럼 의미가 분명히 다르다면 사용해도 무방하다. 요지는 zork라는 변수가 있다는 이유만으로 theZork라 이름 지어서는 안된다는 말이다.

읽는 사람이 차이를 알도록 이름을 지어라.

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

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

흠 여기 BCR3Cntapsgqint 가 있군요 보입니까?

발음하기 쉬운 이름은 중요하다. 프로그래밍은 사회 활동이기 때문이다.

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;
}

위 코드에0서 sum은 별로 유용하진 않으나 최소한 검색이 가능하다. 이름을 의미있게 지으면 함수가 길어진다. 하지만 WORK_DAYS_PER_WEEK를 찾기가 얼마나 쉬운지 생각해보라. 그냥 5가 들어간다면 5가 들어가는 이름을 모두 찾은 후 의미를 분석해 원하는 상수를 가려내야 한다.

인코딩을 피하라

인코딩한 이름은 거의 발음하기 어려우며 오타가 생기기도 쉽다.

헝가리식 표기법

이름 길이가 제한된 언어를 사용하던 옛날에는 어쩔 수 없이 안타까워하면서도 이 규칙을 위반했다. 포트란은 첫 글자로 유형을 표기했다. 초창기 베이식은 글자 하나에 숫자 하나만 허용했다. 헝가리식 표기법은 기존 표기법을 완전히 새로운 단계로 끌어올렸다.

요즘 나오는 프로그래밍 언어는 훨씬 많은 타입을 지원한다. 또한 컴파일러가 타입을 기억하고 강제한다. 게다가 클래스와 함수는 점차 작아지는 추세다. 즉, 변수를 선언한 위치와 사용하는 위치가 멀지 않다.

따라서 이제는 헝가리식 표기법이나 기타 인코딩 방식이 오히려 방해가 될 뿐이다.

변수, 함수, 클래스 이름이나 타입을 바꾸기가 어려워지며, 읽기도 어려워진다. 결국 접두어는 옛날에 작성한 구닥다리 코드라는 징표가 되어버렸다.

인터페이스 클래스와 구현 클래스

때로는 인코딩이 필요한 경우도 있다. 예를 들어 도형을 생성하는 abstract Factory를 구현한다고 가정하자. 이 팩토리는 인터페이스 클래스다. 구현은 구체 클래스에서 한다. 그렇다면 두 클래스 이름을 어떻게 해야할까? IShapeFactory와 ShapeFactory?

저자는 인터페이스 클래스 이름과 구현클래스 이름 중 하나를 인코딩 해야한다면 구현 클래스 이름을 택하겠다고 말한다. ShapeFactoryImp나 심지어 CShapeFactory가 IShapeFactory보다 낫다고 말한다.

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

문자 하나만 사용하는 변수 이름은 문제가 있다. 루프에서 반복 횟수를 세는 변수 i, j, k는 괜찮다 (l은 절대 안 된다!) 단, 루프 범위가 아주 작고 다른 이름과 충돌하지 않을 때만 괜찮다. 그 외에는 대부분 적절하지 못하다. 독자가 실제 개념으로 변환해야 하니까.

최악은 a와 b를 사용하므로 c를 선택한다는 논리다.

일반적으로 프로그래머들은 아주 똑똑하다. 때때로 똑똑한 사람은 자신의 정신적 능력을 과시하고 싶어한다. r이라는 변수가 호스트와 프로토콜을 제외한 소문자 URL이라는 사실을 언제나 기억한다면 확실히 똑똑한 사람이다.

그러나 전문가 프로그래머는 명료함이 최고라는 사실을 이해한다. 따라서 자신의 능력을 좋은 방향으로 사용해 남들이 이해하는 코드를 내놓는다.

클래스 이름

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

메서드 이름

메서드 이름은 동사나 동사구가 적합하다. postPayment, deletePage, save 등이 좋은 예다. 접근자, 변경자, 조건자는 javabean 표준에 따라 값 앞에 get set is를 붙인다.

기발한 이름은 피하라

이름이 기발하면 저자와 유머 감각이 비슷한 사람만, 그리고 농담을 기억하는 동안만, 이름을 기억한다. HolyHandGrenade라는 함수가 무엇을 하는지 알겠는가? 기발한 이름이지만 DeleteItems가 더 좋다.

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

추상적인 개념 하나에 한 단어만 선택해 이를 고수한다. 예를 들어 같은 메서드를 클래스마다 fetch, retrieve, get으로 제각각 부르면 혼란스럽다. 어느 클래스에서 어느 이름을 썼는지 기억하기 어렵다. 마찬가지로 동일 코드 기반에 controller, manager, driver를 섞어 쓰면 혼란스럽다.

이름이 다르면 독자는 당연히 클래스도 다르고 타입도 다르리라 생각한다.

말장난을 하지 마라

한 단어를 두 가지 목적으로 사용하지 마라. 다른 개념에 같은 단어를 사용한다면 그것은 말장난에 불과하다.

때로는 프로그래머가 같은 맥락이 아닌데도 '일관성'을 고려해 add라는 단어를 선택한다. 예를 들어, 지금까지 구현한 add 메서드는 모두가 기존 값 두 개를 더하거나 이어서 새로운 값을 만든다고 가정하자. 새로 작성하는 메서드는 집합에 값 하나를 추가한다. 이 메서드를 add라고 불러도 될까? 하지만 새 메서드는 기존 add와 맥락이 다르다. 그러므로 insert나 append라는 이름이 적당하다. 새 메서드를 add라 부른다면 이는 말장난이다.

의미를 해독할 책임이 독자에게 있는 논문 모델이 아니라 의도를 밝힐 책임이 저자에게 있는 잡지 모델이 바람직하다.

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

코드를 읽을 사람도 프로그래머인다. 그러므로 전산용어, 알고리즘 이름, 패턴 이름, 수학 용어 등을 사용해도 괜찮다. 모든 이름을 문제 영역에서 가져오는 정책은 현명하지 못하다. 같은 개념을 다른 이름으로 이해하던 동료들이 매번 고객에게 의미를 물어야 하기 때문이다.

기술 개념에는 기술 이름이 가장 적합한 선택이다.

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

적절한 프로그래머 용어가 없다면 문제 영역에서 이름을 가져온다. 그러면 코드를 보수하는 프로그래머가 분야 전문가에게 의미를 물어 파악할 수 있다.

문제 영역 개념과 관련이 깊은 코드라면 문제 영역에서 이름을 가져와야 한다.

의미 있는 맥락을 추가하라

스스로 의미가 분명한 이름이 없지 않다. 하지만 대다수 이름은 그렇지 못하다. 그래서 클래스, 함수, 이름 공간에 넣어 맥락을 부여한다. 모든 방법이 실패하면 마지막 수단으로 접두어를 붙인다.

예를 들어 firstName, lastName, street, houseNumber, city, state, zipcode는 주소라는 사실을 금방 알아낸다. 하지만 어느 메서드가 state라는 변수 하나만 사용한다면? 변수 state가 주소 일부라는 사실을 금방 알아챌까?

addr이라는 접두어를 추가해 addrFirstName, addrLastName, addrState라 쓰면 맥락이 좀 더 분명해진다.

물론 Address라는 클래스를 생성하면 더 좋다. 그러면 변수가 좀 더 큰 개념에 속한다는 사실이 컴파일러에게도 분명해진다. 이렇게 맥락을 개선하면 함수를 쪼개기가 쉬워지므로 알고리즘도 좀 더 명확해진다.

불필요한 맥락을 없애라

고급 휘발유 충전소 (Gas Station Deluxe) 라는 애플리케이션을 짠다고 가정하자. 모든 클래스 이름을 GSD로 시작하겠다는 생각은 전혀 바람직하지 못하다.

솔직히 전봇대로 이 쑤시는 격이다.

IDE에서 G를 입력하고 자동 완성 키를 누르면 IDE는 모든 클래스를 열거한다. IDE는 개발자를 지원하는 도구이다. IDE를 방해할 이유는 없다.