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

 

짐작하기 어렵다. 왜?

복잡한 문장은 없다.

고백과 들여 쓰기도 적당하다.

변수는 세 개, 상수는 두 개뿐

화려한 클래스나 다형 메서드도 없다.

단지 배열 목록만 사용한다.

 

무제는 코드의 단순성이 아니라 코드의 함축성이다. 다시 말해, 코드 맥락이 코드 자체에 명시적으로 드러나지 않는다.

독자가 다음과 같은 정보를 안다고 가정한다.

 

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

 

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

 

그릇된 정보를 피하라

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

계정을 담는 컨테이너가 실제 List가 아니라면 프로그래머에게 그릇된 정보를 제공하는 셈이다.

accountGroup, bunchOfAccounts, 아니면 단순히 Accounts라 명명한다.

 

서로 흡사한 이름을 사용하지 않도록 주의한다.

 

의미 있게 구분하라

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

이름이 달라야 한다면 의미도 달라져야 한다.

 

Product라는 클래스가 있다고 가정하자. ProductInfo와 ProductData 클래스와 개념을 구분하지 않을 채 이름만 달리 한 경우다. Info나 Data는 a, an , the와 마찬가지로 의미가 불분명한 불용어다.

 

명확한 관례가 없다면 변수 moneyAmount는 money와 구분이 안 된다. customerInfo는 customer와, accountData는 account와, theMessage는 message와 구분이 안 된다.

 

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

 

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

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

 

"마이키, 이 레코드 좀 보세요. 'Generation Timestamp' 값이 내일 날짜입니다!" 둘째 코드는 지적인 대화가 가능해진다.

 

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

이름의 길이는 범위 크기에 비례해야 한다. 변수나 상수를 코드 여러 곳에서 사용한다면 검색하기 쉬운 이름이 바람직하다.

const int WORK_DAYS_PERWEEK = 5;

찾기가 얼마나 쉬운지 생각해보라. 그냥 5를 사용한다면 5가 들어가는 이름을 모두 찾은 후 의미를 분석해야 한다.

 

인코딩을 피하라

변수나 클래스에 부가적인 정보를 덧붙여 작성하는 것을 뜻한다.

 

- 헝가리식 표기법

IDE가 부실하던 시대에 필요했던 방식이다.

변수 이름 앞에 타입을 명시하지 말자.

 

- 멤버 변수 접두어

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

구분해주는 IDE를 사용하자.

결국은 접두어는 옛날에 작성한 구닥다리 코드라는 징표가 돼버린다.

 

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

IShapeFactory와 ShaperFactory, 개인적으로 인터페이스 이름은 접두어를 붙이지 않는 편이 좋다고 생각한다.

인터페이스라는 사실을 남에게 알리고 싶지 않다. 클래스 사용자는 그냥 ShapeFactory라고만 생각하면 좋겠다.

인터페이스 이름과 구현 클래스 이름 중 하나를 인코딩해야 한다면 구현 클래스 이름을 택하겠다. ShaperFatoryImp

 

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

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

 

클래스 이름

클래스 이름과 객체 이름은 명사나 명사구가 적합하다.

Customer, WikiPage, Account, AddressParser 등 좋은 예,

Manager, Processor, Data, Info 등과 같은 단어는 피하고, 동사는 사용하지 않는다.

 

메서드 이름

메서드 이름은 동사나 동사구가 적합하다.

postPayment, deletePage, save 등이 좋은 예,

 

생성자를 중복 정의할 때는 정적 팩토리 메서드를 사용한다.

Complex fulcrumPoint = Complex.FromRealNumber(23.0);

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

Complex fulcrumPoint = new Complex(23.0);

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

 

기발한 이름은 피하라

HolyHandGrenade라는 함수가 무엇을 하는지 알겠는가? 기발한 이름이지만 DeleteItems가 더 좋다.

재미난 이름보다 명료한 이름을 선택하라. 의도를 분명하고 솔직하게 표현하라.

 

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

똑같은 메서드를 클래스마다 fetch, retrieve, get으로 제각각 부르면 혼란스럽다.

DeviceManager와 ProtocolController는 근본적으로 어떻게 다른가? 어째서 둘 다 Controller가 아닌가? 어째서 둘 다 Manager가 아닌가? 정말 둘 다 Driver가 아닌가? 이름이 다르면 독자는 당연히 클래스도 다르고 타입도 다르리라 생각한다.

일관성 있는 어휘는 코드를 사용할 프로그래머가 반갑게 여길 선물이다.

 

말장난을 하지 마라

한 단어를 두 가지 목적으로 사용하지 마라.

지금까지 구현한 add 메서드는 모두가 기존 값 두 개를 더하거나 이어서 새로운 값을 만든다고 가정한다.

새로 작성하는 메서드는 집합에 값 하나를 추구한다. 이 메서드는 add라 불러도 괜찮을까? 맥락이 다르다.

따라서 insert나 append라는 이름이 적당하다.

 

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

코드를 읽을 사람도 프로그래머라는 사실을 명심한다. 전산 용어, 알고리즘 이름, 패턴 이름, 수학 용어 등을 사용해도 괜찮다.

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

 

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

적절한 "프로그래머 용어"가 없다면 문제 영역에서 이름을 가져온다. 

 

의미 있는 맥락을 추가하라

스스로 의미가 분명한 이름이 없지 않다. 하지만 대다수 이름은 그렇지 못하다. 그래서 클래스, 함수, 이름 공간에 넣어 맥락을 부여한다.

그럼에도 모든 방법이 실패하면 마지막 수단으로 접두어를 붙인다.

 

firstName, lastName, street, houseNumber, city, state, zipcode라는 변수가 있다. 주소라는 사실을 금방 알아챈다.

어느 메서드가 state라는 변수 하나만 사용한다면? state가 주소 일부라는 사실을 금방 알아챌까?

addr라는 접두어를 추가해 addrFirstName, addrListName, 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";
        pluralModifer = "";
    } else {
        number = Integer.toString(count);
        verb = "are";
        pluralModifier = "s";
    }
    String guessMessage = String.format(
      "There %s %s %s%s", verb, number, candidate, pluralmodifier
    );
    print(guessMessage);
}

일단 함수가 좀 길다. 세 변수를 함수 전반에서 사용한다. 좀 더 명확하게 바꿔보자.

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

 

불필요한 맥락을 없애라

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

accountAddress와 customerAddress는 Address클래스 인스턴스로는 좋은 이름이나 클래스 이름으로는 적합하지 못하다.

Address는 클래스 이름으로 적합하다.