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

소프트웨어에서 이름은 어디나 쓰인다. 우리는 변수에도 이름을 붙이고, 함수에도 이름을 붙이고, 소스 파일이 담긴 디렉토리에도 이름을 붙인다. jar 파일에도 이름을 붙이고 war 파일에도 이름을 붙이고.. 여기저기 이름을 사용한다. 이렇듯 이름을 잘 지으면 여러모로 편하다. 이 번에는 이름을 잘 짓는 간단한 규칙을 몇가지 배우게 된다.

의도를 분명히 밝혀라

의도가 분명한 이름은 매우 중요하다. 좋은 이름을 지으러면 시간이 걸리지만, 좋은 이름으로 절약하는 시간이 훨씬 더 많이 소요되고 코드를 읽는 사람이 좀 더 행복해질 수 있다.

변수나 함수 그리고 클래스 이름은 다음과 같은 굵직한 질문에 모두 답해야 한다. 변수의 존재 이유는? 수행 기능은? 사용 방법은? 
만약 따로 주석이 필요하다면 의도를 분명히 드러내지 못했다는 말이다. 예를들어 아래의 코드를 보자.

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

복잡한 코드가 아님에도 코드가 하는 일을 짐작하기가 어렵다. 공백과 들여쓰기도 적당하다. 변수도 3개 뿐이고 상수도 2개 뿐이다. 화려한 클래스나 다형 메서드도 없다. 단지 배열 목록만 사용할 뿐이다.

문제는 코드의 단순성이 아니라 코드의 함축성이다. 다시말해, 코드 맥락이 코드 자체에 명시적으로 드러나지 않는다. 위 코드는 암암리에 독자가 다음과 같은 정보를 안다고 가정하고 있다.

1. theList에 무엇이 들었는가?
2. theList에서 0번째 값이 어째서 중요한가?
3. 값 4는 무슨 의미인가?
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;
}

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

한 걸음 더 나아가 int 배열을 사용하는 대신, 칸을 간단한 클래스로 만들어보자. 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는 변수 이름으로 적합하지 않다. 유닉스 플랫폼이나 유닉스 변종을 가리키는 이름이기 때문이다. 직각삼각형의 빗면을 구현할 때는 hp가 훌륭한 약어가 될 수 있지만, 독자에게 그릇된 정보를 제공할 수도 있다.

여러 계정을 그룹으로 묶을 때, 실제 List가 아니라면, accountList라 명명하지 않는다. 계정을 담는 컨테이너가 실제 List가 아니라면 프로그래머에게 그릇된 정보를 제공하는 셈이기 때문이다. 그러므로 accountGroup, bunchOfAccounts, Accounts라 명명하는 것이 더 적절한 네이밍이 된다.

그리고 서로 흡사한 이름을 사용하지 말자. 한 모듈에서 XYZControllerForEfficientHandlingOfStrings라는 이름을 사용하고, 조금 떨어진 모듈에서 XYZControllerForEfficientStorageOfStrings라는 이름을 사용한다면? 차이를 알아채기 너무 힘들다. 

이름으로 그릇된 정보를 또 다른 예시는 소문자 L이나 대문자 O 변수다. 두 변수를 한꺼번에 사용하면 더욱 끔찍해진다. 아래의 코드를 보면 소문자 L은 숫자 1처럼 보이고, 대문자 O는 숫자 0처럼 보인다.

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

의미있게 구분하라

컴파일러나 인터프리터만 통과하려는 생각으로 코드를 구현하는 프로그래머는 스스로 문제를 일으키게 된다. 예를 들어, 동일한 범위 안에서는 다른 두 개념에 같은 이름을 사용하지 못하기 때문에, 귀찮다는 이유로 한쪽 이름을 마음대로 바꾸고 싶은 유혹이 생긴다. 

컴파일러를 통과할지라도 연속된 숫자를 덧붙이거나 noise word를 추가하는 방식은 적절하지 못하다. 이름이 달라야 한다면 의미도 달라야 한다. 예를들어 연속적인 숫자를 덧붙인 이름 a1, a2 ... aN을 생각해보자. 이런 이름은 그릇된 정보를 제공하는 이름도 아닐뿐만 아니라 어떠한 정보도 제공하지 못하는 이름일 뿐이다. 아래의 코드를 살펴보자.

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

메서드가 넘겨받는 배열들이 대체 어떤 역할을 하는걸까? 변수의 의미가 불분명하기 때문에 코드를 작성한 사람도 시간이 지나면 이해하지 못할 것이다. 명확한 관례가 없다면 변수 a1과 a2는 구분이 되질 않는다. 읽는 사람이 차이를 알 수 있도록 이름을 짓도록 하자.

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

사람들은 단어에 능숙하다. 그리고 정의상으로 단어는 발음이 가능하기에 발음하기 쉬운 이름을 선택하도록 하자.
발음하기 어려운 이름은 토론하기도 어렵다. 예를들어 코드를 살펴보기로 하자.

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

어떤 코드가 더 대화하기 쉬울까? 당연히 아래의 코드이다.

인코딩을 피하라

굳이 부담을 더하지 않아도 이름에 인코딩을 하지말자. 많은 정보가 인코딩 될 수록 그만큼 이름은 해독하기 어려워진다. 문제 해결에 집중하는 개발자에게 인코딩은 불필요한 정신적 부담을 안겨줄 뿐이다. 또한 인코딩한 이름은 거의 발음하기 어려우며 오타가 생기기도 쉽다. 

기억력을 믿지 말자

코드를 읽을 때 변수 이름을 자신이 아는 이름으로 변환해야 한다면 그 변수 이름은 바람직하지 못하다. 이는 일반적으로 문제 영역이나 해법 영역에서 사용하지 않는 이름을 선택했기 때문에 생기는 문제이다.

문자 하나만 사용하는 변수 이름은 문제가 있다. 루프에서 반복 횟수를 세는 변수 i, j, k 정도는 괜찮다. 단, 루프 범위가 아주 작고 다른 이름과 충돌하지 않을 때만 괜찮다. 그 외에는 대부분 적절하지 못한 변수명일 것이다. 

똑똑한 프로그래머와 전문가 프로그래머 사이에서 나타나는 차이점은, 전문가 프로그래머는 명료함이 최고라는 사실을 우선시 한다는 점이다. 따라서 전문가는 자신의 능력을 좋은 방향으로 사용해 남들이 이해하는 코드를 만들게 된다.

클래스 이름

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

메서드 이름

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

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

그리고 생성자를 중복 정의할 때는 정적 팩토리 메소드를 사용하는 것이 좋다. 메소드의 이름은 인수를 설명하도록 사용하곤 한다. 아래의 두 코드를 살펴보자.

Complex fulcrumPoint = Complex.FromRealNumber(23.0);

Complex fulcrumPoint = new Complex(23.0);

당연하게도 위의 코드가 아래의 코드보다 좋다.

기발한 이름은 피하라

이름이 너무 기발하면, 저자와 유머 감각이 비슷한 사람만, 그리고 농담을 기억하는 동안만 기억할 수 있을 것이다. 예를들어 'HolyHandGrenade'라는 함수가 있다면 무엇을 의미하는지 알 수 없다. 반면 DeleteItems와 같은 이름은 메서드의 역할을 명확하게 알 수 있다. 특정 문화에서만 사용하는 농담은 피하는 것이 좋다. 의도를 분명하고 솔직하게 나타내자.

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

추상적인 개념 하나에 단어 하나를 선택해 이를 고수하자. 예를들어 똑같은 메서드를 클래스마다 fetch, retrieve, get 등으로 제각각 부르면 혼란스럽다. 어느 클래스에서 어느 이름을 썼는지 모든걸 기억할 수 있을까?

메서드 이름은 독자적이고 일관적이어야 한다. 그래야 주석을 뒤져보지 않고도 프로그래머가 올바른 메서드를 선택할 수 있다. 이름이 다르면 해당 코드를 읽는 프로그래머는 당연히 클래스도 다르고 타입도 다를 것이라 생각한다. 일관성 있는 어휘는 나중에 코드를 사용할 다른 동료 프로그래머가 반갑게 여길 선물이 될 수 있다.

말장난을 하지 마라

한 단어를 두 가지 목적으로 사용하지 말자. 다른 개념에 같은 단어를 사용한다면 그것은 말장난에 불과하다.
이 규칙을 따른다면, 여러 클래스에 add라는 메서드가 생길 수 있다. 이 메서드의 매개변수와 반환값이 의미적으로 똑같다면 큰 문제는 없다.

하지만, 때로는 프로그래머가 같은 맥락이 아님에도 일관성을 고려해 add라는 단어를 선택할 수 있다. 예를들어, 지금까지 구현한 add 메서드는 모두가 기존 값 두 개를 더하거나 이어서 새로운 값을 만든다고 가정하자. 이때 새로운 메서드에 값 하나를 추가하면, 이 메서드를 add로 선언해도 될까? 이 메서드는 기존 add 메서드와 맥락이 다르다. 그러므로, insert나 append라는 새로운 이름이 적절하다. 

프로그래머는 코드를 최대한 이해하기 쉽게 짜야 한다. 대충 훑어봐도 이해할 정도의 코드를 작성할 수 있다면 가장 좋을 것이다.

의미 있는 맥락을 추가하라

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

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

그래서 addr라는 접두어를 추가해 addrFirstName, addrLastName, addrState라 쓰면 맥락이 좀 더 분명해질 수 있다. 변수가 좀 더 큰 구조에 속한다는 사실이 적어도 독자에게는 분명해지는 것이다. 

아래의 코드를 살펴보자.

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라는 변수 3개가 guess statistics 메시지에 사용된다는 사실이 드러난다. 불행히도 코드를 읽는 프로그래머가 맥락을 유추해야만 하고, 그냥 메서드만 봤을땐 세 변수의 의미가 불분명하다.

그리고 함수가 좀 길고, 세 변수를 함수 전반에서 사용하고 있다. 
그래서 아래와 같이 함수를 작은 조각으로 쪼개고자 GuessStatisticsMessage라는 클래스를 만든 후 세 변수를 클래스에 넣었다. 

public class GuessStatisticsMessage {

    private String number;
    private String verb;
    private String pluralModifier;
    
    public String make(char candidate, int count) {
        createPluralDependentMessageParts(count);
        return String.format(
            "There %s %s %s%s", 
            verb, number, candidate, pluralModifier);
    }
    
    private void createPluralDependentMessageParts(int count) {
        if (count == 0) {
            thereAreNoLetters();
        } else if (count == 1) {
            thereIsOneLetter();
        } else {
            thereAreManyLetters(count);
        }
    }
    
    private void thereAreNoLetters() {
        number = "no";
        verb = "are";
        pluralModifier = "s";
    }
    
    private void thereIsOneLetter() {
        number = "1";
        verb = "is";
        pluralModifier = "";
    }
    
    private void thereAreManyLetters(int count) {
        number = Integer.toString(count);
        verb = "are";
        pluralModifier = "s";
    }
}

이제 세 변수의 맥락이 분명해졌다. 즉 세 변수는 확실하게 GuessStatisticsMessage에 속한다. 그리고 함수를 쪼개기가 쉬워지면서 알고리즘도 좀 더 명확해졌다.

Ref : Clean Code