[Clean Code] 2장 - 의미 있는 이름

소프트웨어에서 이름은 어디나 쓰인다. 우리는 변수에도 이름을 붙이고, 함수에도 이름을 붙이고, 인수와 클래스와 패키지에도 이름을 붙인다. 이렇듯 많이 사용하므로 이름을 잘 지으면 여러모로 편하다. 이 장에서는 이름을 잘 짓는 간단한 규칙 몇 가지 소개한다.

의도를 분명히 밝혀라

"의도가 분명하게 이름을 지으라"고 말하기는 쉽다. 여기서는 의도가 분명한 이름이 정말로 중요하다는 사실을 거듭 강조한다. 좋은 이름을 지으려면 시간이 걸리지만 좋은 이름으로 절약하는 시간이 훨씬 더 많다. 그러므로 이름을 주의깊게 살펴 더 나은 이름이 떠오르면 개선하기 바란다. 그럼 코드를 읽는 사람이 좀 더 행복해지리라.

의도가 드러나는 이름을 사용하면 코드 이해와 변경이 쉬워진다. 다음 코드는 무엇을 할까?

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을 어떻게 사용하는가?

위 코드 샘플엔 이와 같은 정보가 드러나지 않는다. 하지만 정보 제공은 충분히 가능했었다. 지뢰찾기 게임을 만든다고 가정하자. 그러면 theList가 게임판이라는 사실을 안다. thisList를 gameBoard로 바꿔보자. 각 개념에 이름만 붙여도 코드가 상당히 나아진다.

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

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

그릇된 정보를 피하라

프로그래머는 코드에 그릇된 단서를 남겨서는 안 된다. 그릇된 단서는 코드 의미를 흐린다. 나름대로 널리 쓰이는 의미가 있는 단어를 다른 의미로 사용해도 안 된다. 예를 들어, hp, aix, sco는 변수 이름으로 적합하지 않다. 여러 계정을 그룹으로 묶을 때, 실제 List가 아니라면 accountList라 명명하지 않는다. 프로그래머에게 List라는 단어는 특수한 의미다. 서로 흡사한 이름을 사용하지 않도록 주의 한다. XYZControllerForEfficientHandlingOfStrings라는 이름을 사용하고 다른 모듈에서 XYZControllerForEfficientStorageOfStrings라는 이름을 사용한다면? 차이를 알아챘는가? 두 단어는 겁나게 비슷하다.

의미 있게 구분하라

연속된 숫자를 덧붙이거나 불용어를 추가하는 방식은 적절하지 못하다. 이름이 달라야 한다면 의미도 달라져야 한다. 연속적인 숫자를 덧붙인 이름(a1, a2, ... aN)은 의도적인 이름과 정반대다. 이런 이름은 그릇된 정보를 제공하는 이름도 아니며, 아무런 정보를 제공하지 못하는 이름일 뿐이다. 다음 코드를 살펴보자.

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와 마찬가지로 의미가 불분명한 불용어다. 읽는 사람이 차이를 알도록 이름을 지어라.

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

사람들은 단어에 능숙하다. 우리 두뇌에서 상당 부분은 단어라는 개념만 전적으로 처리한다. 발음하기 쉬운 이름은 중요하다. 프로그래밍은 사회 활동이기 때문이다. 다음 두 예제를 비교해보자.

class DtaRcrd102 {
    private Date genymdhms;
    private Date modymdhms;
    private final String pszqint = "102";
    /* ... */
}

와

class Customer {
    private Date generaltionTimestamp;
    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;
}

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

인코딩을 피하라

굳이 부담을 더하지 않아도 이름에 인코딩할 정보는 아주 많다. 유형이나 범위정보까지 인코딩에 넣으면 그만큼 이름을 해독하기 어려워진다. 인코딩한 이름은 거의가 발음하기 어려우며 오타가 생기기도 쉽다. 자바 프로그래머는 변수 이름에 타입을 인코딩할 필요가 없다. 객체는 강한타입이며, IDE는 코드를 컴파일하지 않고도 타입 오류를 감지할 정도로 발전했다. 따라서 이제는 헝가리식 표기법이나 기타 인코딩 방식이 오히려 방해가 될 뿐이다.

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

이제는 멤버 변수에 m_ 이라는 접두어를 붙일 필요도 없다. 클래스와 함수는 접두어가 필요없을 정도로 작아야 마땅하다.

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

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

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

때로는 인코딩이 필요한 경우도 있다. 예를 들어, 도형을 생성하는 ABSTRACT FACTORY를 구현한다고 가정하자. 이 팩토리는 인터페이스 클래스다. 구현은 구체 클래스에서 한다. 그렇다면 두 클래스 이름을 어떻게 지어야 좋을까? 개인적으로 인터페이스 이름은 접두어를 붙이지 않는 편이 좋다고 생각한다. 옛날 코드에서 많이 사용하는 접두어 i 는 주의를 흐트리고 과도한 정보를 제공한다. 나로서는 내가 다루는 클래스가 인터페이스라는 사실을 남에게 알리고 싶지 않다. 클래스 사용자는 그냥 ShapeFactory라고만 생각하면 좋겠다. 그래서 인터페이스 클래스 이름과 구현 클래스 이름 중 하나를 인코딩해야 한다면 구현 클래스 이름을 택하겠다. ShapeFactoryImp나 심지어 CShapeFactory가 IShapeFactory보다 좋다.

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

독자가 코드를 읽으면서 변수 이름을 자신이 아는 이름으로 변환해야 한다면 그 변수 이름은 바람직하지 못하다. 이는 일반적으로 문제 영역이나 해법 영역에서 사용하지 않는 이름을 선택했기 때문에 생기는 문제다. 문자 하나만 사용하는 변수 이름은 문제가 있다. 루프에서 반복 횟수를 세는 변수 i, k, j는 괜찮다 단, 루프 범위가 아주 작고 다른 이름과 충돌하지 않을 때만 괜찮다. 똑똑한 프로그래머와 전문가 프로그래머 사이에서 나타나는 차이점 하나만 들자면, 전문가 프로그래머는 명료함이 최고라는 사실을 이해한다. 전문가 프로그래머는자신의 능력을 좋은 방향으로 사용해 남들이 이해하는 코드를 내놓는다.

클래스 이름

클래스 이름과 객체 이름은 명사나 명사구가 적합하다. 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);

생성자 사용을 제한하려면 해당 생성자를 private으로 선언한다.

기발한 이름은 피하라

이름이 너무 기발하면 저자와 유며 감각이 비슷한 사람만, 그리고 농담을 기억하는 동안만, 이름을 기억한다. 간혼 프로그래머가 나름대로 재치를 발휘해 구어체나 속어를 이름으로 사용하는 사례가 있다. 특정 문화에서만 사용하는 농담은 피하는 편이 좋다. 의도를 분명하고 솔직하게 표현하라.

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

추상적인 개념 하나에 단어 하나를 선택해 이를 고수한다. 예를 들어, 똑같은 메소드를 클래스마다 fetch, retrieve, get으로 제각각 부르면 혼란스럽다. 메서드 이름은 독자적이고 일관적이어야 한다. 그래야 주석을 뒤져보지 않고도 프로그래머가 올바른 메소드를 선택한다. 일관성 있는 어휘는 코드를 사용할 프로그래머가 반갑게 여길 선물이다.

말장난을 하지 마라

한 단어를 두 가지 목적으로 사용하지 마라. 다른 개념에 같은 단어를 사용한다면 그것은 말장난에 불과하다. 예를 들어, 지금까지 구현한 add 메서드는 모두가 기존 값 두개를 더하거나 이어서 새로운 값을 만든다고 가정하자. 새로 작성하는 메서드는 집합에 값 하나를 추가한다. 이 메서드를 add라 불러도 괜찮을까? add라는 메서드가 많으므로 일관성을 지키려면 add라 불러야 하지 않을까? 하지만 새 메서드는 기존 add 메서드와 맥락이 다르다. 그러므로 isert나 append라는 이름이 적당하다. 새 메서드를 add라 부른다면 이는 말장난이다. 프로그래머는 코드를 최대한 이해하기 쉽게 짜야 한다.

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

코드를 읽을 사람도 프로그래머라는 사실을 명심한다. 그러므로 전산 용어, 알고리즘 이름, 패턴 이름, 수학 용어 등을 사용해도 괜찮다. 모든 이름을 도메인에서 가져오는 정책은 현명하지 못하다.

의미 있는 맥락을 추가하라

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

불필요한 맥락을 없애라

일반적으로는 짧은 이름이 긴 이름보다 좋다. 단, 의미가 분명한 경우에 한해서다. 이름에 불필요한 맥락을 추가하지 않도록 주의한다.

결론

좋은 이름을 선택하려면 설명 능력이 뛰어나야 하고 문화적인 배경이 같아야 한다. 좋은 이름을 선택하는 능력은 기술, 비즈니스, 관리 문제가 아니라 교육 문제다. 우리 분야 사람들이 이름 짓는 방법을 제대로 익히지 못하는 이유가 바로 여기에 있다. 이 장에서 소개한 규칙 몇개를 적용해 코드 가독성이 높아지는지 살펴보라. 다른 사람이 짠 코드를 손본다면 리팩터링 도구를 사용해 문제 해결 목적으로 이름을 개선하라. 단기적인 효과는 물론 장기적인 이익도 보장한다.