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

위 코드는 하는 일을 짐작하기 어렵다. 복잡한 문장은 없다. 단지 배열 목록만 사용한다.

 

여기서 문제는 코드의 단순성이 아니라 코드의 함축성이다. 코드 맥락이 코드 자체에 명시적으로 드러나지 않는다. 위 코드는 다음과 같은 정보를 안다고 가정한다.

• theList에 무엇이 들었는가?
• theList에서 0번째 값이 어째서 중요한가?
• 값 4는 무슨 의미인가?
• 함수가 반환하는 리스트 list1을 어떻게 사용하는가?

위 코드에서는 이와 같은 정보가 드러나지 않는다. 하지만 정보 제공은 충분히 가능했었다. 

 

이 코드는 지뢰찾기 게임을 만들기 위한 코드라고 가정하자. 그러면 theList가 게임판이라는 사실을 안다. theList를 gameBoard로 바꿔보자.

 

게임판에서 각 칸은 단순 배열로 표현한다. 배열에서 0번째 값은 칸 상태를 뜻한다. 값 4는 깃발이 꽂힌 상태를 가리킨다. 각 개념에 이름만 붙여도 코드가 상당히 나아진다.  

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

코드의 단순성은 변하지 않았다. 그런데도 코드는 더욱 명확해졌다.

 

한 걸음 더 나아가, 칸을 배열 대신 간단한 클래스로 만들어도 되겠다. isFlagged라는 좀 더 명시적인 함수를 사용해 FLAGGED라는 상수를 감춰도 좋겠다. 새롭게 개선한 결과는 다음과 같다.

public List<Cell> getFlaggedCells() {
    List<Cell> flaggedCells = new ArrayList<Cell>();
    for(Cell cell : gameBoard) {
        if(cell.isFlagged()) {
            flaggedCells.add(cell);
        }
    }
    return flaggedCells;
}

이름만 고쳤는데도 함수가 하는 일을 이해하기 쉬워졌다. 바로 이것이 좋은 이름이 주는 위력이다.

 

그릇된 정보를 피하라

프로그래머는 코드에 그릇된 단소를 남겨서는 안 된다. 그릇된 단서는 코드 의미를 흐린다. 나름 널리 쓰이는 의미가 있는 단어를 다른 의미로 사용하면 안 된다. 예를 들어 hp, aix, sco는 유닉스 플랫폼이나 변종을 가리키는 이름이기 때문에 변수 이름으로 적절하지 않다. 빗변(hypotenuse)을 담는 변수로 hp가 훌륭한 약어로 보일지라도 이는 그릇된 정보를 제공한다.

 

여러 계정을 그룹으로 묶을 때, 실제 List가 아니라면, accountList라 명명하지 않는다. 프로그래머에게 List라는 단어는 특수한 의미이기 때문이다. 그러므로 accountGroup, bunchOfAccounts 아니면 단순히 Account라 명명한다.

 

이름으로 그릇된 정보를 제공하는 끔찍한 예는 소문자 L이나 대문자 O 변수이다. 두 변수를 한꺼번에 사용하면 더욱 끔찍해진다.

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

다음 코드에서 보듯, 소문자 L은 숫자 1처럼 보이고 대문자 O는 숫자 0처럼 보인다.

 

의미 있게 구분하라

동일한 범위 안에서는 다른 두 개념에 같은 이름을 사용하지 못한다. 그래서 프로그래머가 한쪽 이름을 마음대로 바꾸고픈 유혹에 빠진다. 컴파일러를 통과할지라도 연속된 숫자를 덧붙이거나 불용어를 추가하는 방식은 적절하지 못하다. 이름이 달라야 한다면 의미도 달라져야 한다. 

 

연속적인 숫자를 덧붙인 이름(a1, a2, ..., aN)은 의도적인 이름과 정반대이다. 이런 이름은 그릇된 정보를 제공하는 이름도 아니며, 아무런 정보를 제공하지 못하는 이름일 뿐이다. 다음 코드를 살펴보자.

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

이 난해한 함수는 a1을 source, 그리고 a2를 destination으로만 바꿔도 코드 읽기가 훨씬 더 쉬워진다.

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

 

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

 

불용어는 중복이다. 변수 이름에 variable이라는 단어는 금물이다. 표 이름에 table이라는 단어도 마찬가지다. NameString이 Name보다 뭐가 나은가? 

 

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

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

예를 들어, genymdhms(generate date, year, month, day, hour, minute, second) 라는 단어를 사용했다. 직원들은 이 변수를 '젠 와이 엠 디 에이취 엠 에스'라 발음할 것이다. 얼마나 우스꽝 스러운 이름인가? 개발자는 이런 단어를 참아가며 개발에 임해야 할 것이다. 다음 둘의 코드를 보면 어떤게 더 나은지 금방 짐작될것이다.

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";
    /* ... */
}

 

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

문자 하나를 사용하는 이름과 상수는 텍스트 코드에서 쉽게 눈에 띄지 않는다는 문제점이 있다. 

 

MAX_CLASSES_PER_STUDENT는 찾기 쉽지만, 숫자 7은 은근히 까다롭다. 7이 들어가는 수식이 모두 검색되기 때문이다. 검색이 되었지만 7을 사용한 의도가 다를 수 있다. 마찬가지로 e라는 문자도 변수 이름으로 적합하지 못하다. 검색이 어려운 탓이다. e는 영어에서 가장 많이 쓰이는 알파뱃이다. 이런 관점에서 긴 이름이 짧은 이름보다 좋다. 검색하기 쉬운 이름이 상수보다 좋다.

 

개인적으로는 간단한 메서드에서 로컬 변수만 한 문자를 사용한다. 이름 길이는 범위 크기에 비례해야 한다. 변수나 상수를 코드 여러 곳에서 사용한다면 검색하기 쉬운 이름이 바람직하다. 다음 두 코드를 비교해보자.

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를 찾기가 얼마나 쉬운지 생각해보라. 그냥 5를 사용한다면 5가 들어가는 이름을 모두 찾은 후 의미를 분석해 원하는 상수를 가려내야 한다.

 

인코딩을 피하라

이름에 인코딩할 정보는 아주 많다. 유형이나 범위정보까지 인코딩에 넣으면 그만큼 이름을 해독하기 어려워진다. 

 

헝가리식 표기법

옛날에는 어쩔 수 없이 이 규칙을 위반했단. 포트란은 첫 글자로 유형을 표현했다. 초창기 베이직은 글자 하나에 숫자 하나만 허용했다. 헝가리식 표기법은 기존 표기법을 완전히 새로운 단계로 끌어올렸다.

 

과거 윈도 C API는 헝가리식 표기법을 굉장히 중요하게 여겼다. 윈도 C API는 모든 변수가 정수 핸들, long 포인터, void 포인터, 여러 문자열 중 하나였다. 당시에는 컴파일러가 타입을 점검하지 않았으므로 프로그래머에게 타입을 기억할 단서가 필요했다.

 

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

 

자바 프로그래머는 변수 이름에 타입을 인코딩할 필요가 없다. 객체는 강한 타입이며, IDE는 코드를 컴파일하지 않고도 타입 오류를 감지할 정도로 발전했다. 따라서 이제는 헝가리식 표기법이나 기타 인코딩 방식이 오히려 방해가 될 뿐이다. 변수, 함수, 클래스 이름이나 타입을 바꾸기가 어려워 지면, 읽기도 어려워진다. 

PhoneNumber phoneString
// 타입이 바뀌어도 이름은 바뀌지 않는다!

 

멤버 변수 접두어

이베는 멤버 변수에 m_이라는 접두어를 붙일 필요도 없다. 클래스와 함수는 접두어가 필요없을 정도로 작아야 마따하다. 또한 멤버 변수를 다른 색상으로 표시하거나 눈에 띄게 보여주는 IDE를 사용해야 마땅하다.

public class Part {
    private String m_dsc; // 설명 문자열
    void setName(String name) {
        m_dsc = name;
    }
}

---

public class Part {
    String description;
    void setDescription(String description) {
        this.description = description;
    }
}

게다가 사람들은 접두어를 무시하고 이름을 해독하는 방식을 재빨리 익힌다. 코드를 읽을수록 접두어는 관심 밖으로 밀려난다. 결국 접두어는 옛날에 작성한 구식 코드라는 징표가 되버린다.

 

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

때로는 인코딩이 필요한 경우도 있다. 도형을 생성하는 Abstract Factory를 구현한다고 가정하자. 이 팩토리는 인터페이스 클래스이다. 구현은 상세 클래스에서 한다. 그렇다면 두 클래스 이름을 어떻게 지어야 좋을까? IShapeFactory? ShapeFactory? 개인적으로 인터페이스 이름은 접두어를 붙이지 않는 편이 좋다. 접두어 I는 주의를 흐트리고 과도한 정보를 제공한다. 클래스 사용자는 그냥 ShapeFactory라고만 생각하면 좋겠다. 인터페이스 클래스보다는 구현 클래스로 명시 하는 것이 더 보기 좋을 것이다. ShapeFactoryImp나 심지어는 CShapeFacotry가 IShapeFatory보다 좋다.

 

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

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

 

똑똑한 프로그래머와 전문가 프로그래머 사이의 차임점 하나만 들자면, 전문가 프로그래머는 명료함이 최고라는 사실을 이해한다.

 

클래스 이름

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

 

메서드 이름

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

String name = employee.getName();
customer.setName("mike");
if(paycheck.isPosted()) ...

 

생성자를 중복정의 할 때는 정적 팩토리 메서드를 사용한다. 메서드는 인수를 설명하는 이름을 사용한다. 

Complex fulcrumPoint = Complex.FromRealNumber(23.0);

위 코드가 아래 코드보다 좋다.

Complex fulcrumPoint = new Complex(23.0);

 

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

추상적인 개념 하나에 단어 하나를 선택해 이를 고수한다. 예를들어, 똑같은 메서드를 클래스마다 fetch, retrieve, get으로 제각각 부르면 혼란스럽다. 어느 클래스에서 어느 이름을 썼는지 기억하기 어렵다. 이러한 이름들을 기억하지 못한다면 헤더와 과거 코드 예제를 살피느라 엄청난 시간을 소모하기 십상이다.

 

최신 IDE는 문맥에 맞는 단서를 제공한다. 예를 들어, 객체에 사용하면 그 객체가 제공하는 메서드 목록을 보여준다. 하지만 목록을 보통 함수 이름과 매개변수만 보여줄 뿐 주석은 보여주지 않는다. 따라서 메서드 이름은 독자적이고 일관적이어야 한다. 그래야 주석을 보지 않고도 올바른 메서드를 선택할 수 있다.

 

말장난을 하지 마라

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

 

예를 들어, 여러 클래스에 add라는 메서드가 생겼다. 모든 add 메서드의 매개변수와 반환값이 의미적으로 똑같다면 문제가 없다. 하지만 때로는 프로그래머가 같은 맥락이 아닌데도 '일관성'을 고려해 add라는 단어를 선택한다. 지금까지 구현한 add 메서드는 모두가 기존 값 두 개를 더하거나 이어서 새로운 값을 만든다고 가정하자. 새로 작성한 메서드는 집합에 값 하나를 추가한다. 이 메서드를 add라고 불러도 괜찮을까? add라는 메서드가 많으므로 일관성을 지키려면 add라 불러야 하지만 새 메서드는 기존 add 메서드와 맥락이 다르다. 그러므로 insert나 append라는 이름이 적당하다. 새 매서드를 add라 부른다면 이는 말장난이다.

 

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

코드를 읽을 사람도 프로그래머라는 사실을 명심한다. 그러므로 전산 용어, 알고리즘 이름, 패턴 이름, 수학 용어 등을 사용해도 괜찮다. 모든 이름을 문제 영역(domain)에서 가져오는 정책은 현명하지 못하다. 같은 개념을 다른 이름으로 이해하던 동료들이 매번 고객에게 의미를 물어야하기 때문이다. 프로그래머에게 익숙한 기술 개념은 아주 많다.(JobQueue, AccountVisitor 등) 기술 개념에는 기술 이름이 가장 적합한 선택이다.

 

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

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

 

의미 있는 맥락을 추가하라

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

 

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

 

addr을 접두어로 추가해 addrFirstName, addrLastName, addrState라 쓰면 맥락이 좀 더 분명해진다. 변수가 좀 더 큰 구조에 속한다는 사실이 적어도 독자에게는 분명해진다. 물론 Address라는 클래스를 생성하면 더 좋다. 그러면 변수가 좀 더 큰 개념에 속한다는 사실이 컴파일러에게도 분명해진다.

private void printGuessStatistics(char candidate, int count) {
    String number;
    String verb;
    String pluralModifier;
    if (count == 0) {
        number = "no";
        verb = "are";
        pluralModifier = "s";
    } else if (count == 1) {
        number = "1";
        verb = "is";
        pluralModifier = "";
    } else {
        number = Integer.toString(count);
        verb = "are";
        pluralModifier = "s";
    }
    String guessMessage = String.format(
        "There %s %s %s%s", verb, number, candidate, pluralModifier
    );
    print(guessMessage);
}

위 코드를 살펴보면, 함수 이름은 맥락 일부만 제공하며, 알고리즘이 나머지 맥락을 제공한다. 함수를 끝까지 보고 나서야 number, verb, pluralModifier라는 변수 세 개가 '통계 추측' 메시지에 사용된다는 사실이 드러난다. 불행하게도 독자가 맥락을 유추해야만 한다. 그냥 메서드만 봐서는 세 변수의 의미가 불분명하다. 일단 함수가 좀 길다. 그리고 세 변수는 함수 전반에서 사용한다.

 

위 코드를 개선하면 다음과 같다. 

public class GuessStatisticMesssage {
    String number;
    String verb;
    String pluralModifier;

    public String make(char candidate, int count) {
        createPluralDepentMessageParts(count);
        return String.format(
            "There %s %s %s%s",
            verb, number, candidate, pluralModifier);
    }

    private void createPluralDepentMessageParts(int count) {
        if (count == 0) {
            thereAreNoLetters();
        } else if (count == 1) {
            thereIsOneLetter();
        } else {
            thereAreManyLetters(count);
        }
    }

    private void thereAreManyLetters(int count) {
        number = Integer.toString(count);
        verb = "are";
        pluralModifier = "s";
    }

    private void thereIsOneLetter() {
        number = "1";
        verb = "is";
        pluralModifier = "";
    }

    private void thereAreNoLetters() {
        number = "no";
        verb = "are";
        pluralModifier = "s";
    }
}

함수를 작은 조각으로 쪼개고자 GuessStatisticsMessage라는 클래스를 만든 후 세 변수를 클래스에 넣었다. 그러면 세 변수는 맥락이 분명해지고 확실하게 GuessStatisticsMessage에 속한다. 이렇게 맥락을 개선하면 함수를 쪼개기가 쉬워지므로 알고리즘도 좀 더 명확해진다.

 

불필요한 맥락을 없애라

일반적으로 짧은 이름이 긴 이름보다 좋다. 단, 의미가 분명한 경우에 한해서다. 이름에 불필요한 맥락을 추가하지 않도록 주의한다. accountAddress와 customerAddress는 Address 클래스 인스턴스로는 좋은 이름이나 클래스 이름으로는 적합하지 못하다. Address는 클래스 이름으로 적합하다. 포트 주소, MAC 주소, 웹 주소를 구분해야 한다면 PostalAddress, MAC, URI라는 이름도 괜찮다. 그러면 의미가 좀 더 분명해진다.