[클린코드(CleanCode)] 2장 의미있는 이름

들어가면서

소프트웨어에서 이름은 어디나 쓰이므로 이름 잘 지으면 여러모로 편해진다

이 장에서는 이름을 잘 짓는 간단한 규칙 몇 가지 소개한다

---

의도를 분명히 밝혀라

의도가 분명하게 이름을 지어야 한다

• 좋은 이름을 지으려면 시간이 걸리지만 좋은 이름으로 절약하는 시간이 훨씬 많아진다
• 그러므로, 이름을 주의 깊게 살펴 더 나은 이름이 떠오르면 개선하면 된다
• 변수나 함수 클래스의 존재 이유, 수행 기능, 사용 방법에 대해 주석이 필요하다면 의도를 분명히 드러내지 못한 것이다

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

• 복잡한 문장은 아니지만 코드의 의미가 너무 함축적이라 코드 맥락이 코드 자체에 명시적으로 드러나지 않는다
• 그래서 아래와 같이 암암리에 독자가 다음과 같은 정보를 안다고 가정해야 한다

1. theList에는 무엇이 들어있는지
2. theList에서 0번째 값이 왜 중요한지 -> x[0] == 4 를 체크하는 이유
3. 2에서 값 4는 무슨 의미인지
4. 함수가 반환하는 리스트 list1을 어떻게 사용하는지

• 그럼 이를 지뢰 찾기 게임을 만든다고 가정하자
• 각 숫자 및 변수 이름을 명확하게 바꿔보면 어떨까? 아래와 같이 이해하기 편할 것이다
  • theList는 게임판이었을 테니, gameBoard로 바꾼다
  • 배열 list1에서 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[] 배열을 쓰는 대신, cell 자체를 간단한 클래스로 만들어도 되겠다. isFlagged라는 더 명시적인 함수를 사용해 FLAGGED라는 상수를 감춰보자

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

• 이제 좀 더 함수가 하는 일을 이해하기 쉬워졌다. 이것이 좋은 이름이 주는 위력이다.

---

그릇된 정보는 피하라

프로그래머는 다음과 같은 사항들로 인해, 코드에 그릇된 단서를 남겨서는 안 된다. 그릇된 단서는 코드 의미를 흐린다.

• 나름대로 널리 쓰이는 의미가 있는 단어를 다른 의미로 사용하면 안 된다.
  • 예시) hp, aix, sco
• 서로 흡사한 이름을 사용하지 않도록 주의한다.
  • 한 모듈에서 XYZControllerForEfficientHandlingOfStrings 라고 쓰고 다른 모듈에서 XYZControllerForEfficientStorageOfStrings 라고 쓰면 차이를 알아차리기 힘들다.
• 유사한 개념은 유사한 표기법을 사용한다. 일관성이 떨어지는 표기법은 그릇된 정보다.
• 소문자 L이나 대문자 O로 변수 이름 만들면 헷갈린다

---

의미 있게 구분하라

단순히 컴파일러나 인터프리터만 통과하려는 생각으로 코드를 구현하는 프로그래머는 스스로 문제를 일으킨다.

동일한 범위 안에서 다른 두 개념에 같은 이름을 사용하지 못한다.

• 그렇기 때문에 프로그래머는 한쪽 이름을 마음대로 바꾸고 싶은 유혹에 빠진다.
• 어떤 프로그래머는 철자를 살짝 바꿨다가 나중에 철자 오류를 고치는 순간 컴파일이 불가능한 상황에 빠진다.

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

• 이름이 달라야 한다면 의미도 달라져야 한다
• 연속적인 숫자를 덧붙인 이름(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를 from, to 혹은 source, destination으로 바꾸면 코드 읽기가 훨씬 더 쉬워진다

불용어 추가한 이름 역시 아무런 정보도 제공하지 못한다

• Product라는 클래스가 있다고 가정해 보자. 다른 클래스를 ProductInfo 혹은 ProductData라 부른다면 이는 개념을 구분하지 않은 채 이름만 달리한 경우입니다. Info나 Data는 a, an, the와 마찬가지로 의미가 불분명한 불용어다.
• a나 the와 같은 접두어를 사용하지 말라는 얘기는 아니다. 의미가 분명히 다르다면 사용해도 무방하다. 예를 들어, 모든 지역 변수는 a를 사용하고 모든 함수 인수는 the를 사용해도 되겠지만 요지는 work라는 변수가 있다는 이유만으로 theWork라 이름 지어서는 안 된다는 것이다.

중복된 의미를 피하자

• 불용어는 중복이다. 변수 이름에 variable이라는 단어는 단연코 금물이다. 표 이름에 table이라는 단어도 마찬가지다. NameString이 Name보다 나을 게 무엇인가? Name이 부동 소수가 될 가능성이 있던가? 그렇다면 앞서 언급한 "그릇된 정보를 피하라" 규칙을 위반하는 것이다.
• 코드를 읽다가 Customer라는 클래스와 CustomerObject라는 클래스를 발견했다면 그 차이를 알 수 있을까? 고객 급여 이력을 찾으려면 어느 클래스를 뒤져야 할까?

실제로 이런 오류를 저지르는 예시가 있다

getActiveAccount();
getActiveAccounts();
getActiveAccountInfo();

• 이 프로젝트에 참여한 프로그래머는 어느 함수를 호출할지 어떻게 알까? 명확한 관례가 없다면 변수 moneyAmount는 money와 구분이 안 된다. customerInfo는 customer와, accountData는 account와, theMessage는 message와 구분이 안된다.
• 읽는 사람이 차이를 알도록 이름을 지어야 한다

 

---

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

발음하기 어려운 이름은 토론하기도 어렵기 때문에, 발음하기 쉬운 이름은 중요하다.

• 프로그래밍은 사회 활동이라고 볼 수 있기 때문에 발음하기 쉬운 이름을 사용하는 것이 좋다.
• 발음하기 좋은 단어로 코드를 구현한다면 프로그래머 간 지적인 대화가 가능해진다.

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는 grep으로 찾기가 쉽지만, 숫자 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를 찾기가 얼마나 쉬운지 생각해 보라.

---

인코딩을 피해라

이름에 불필요한 인코딩을 추가하면 코드를 이해하기가 더 어려워진다.

새로운 개발자들은 이미 많은 코드를 익혀야 하는데, 여기에 인코딩이라는 추가적인 부담을 주는 것은 비합리적이다.

인코딩된 이름은 발음하기도 어렵고 오타가 생기기도 쉽다.

헝가리 표기법

과거 윈도우 C API에서는 컴파일러가 타입을 점검하지 않았기 때문에 헝가리식 표기법이 필요했다.

하지만 현대 프로그래밍 언어들은 강력한 타입 시스템을 가지고 있고, 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;
    }
}

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

인터페이스와 구현 클래스의 이름을 지을 때도 불필요한 인코딩은 피해야 한다.

IShapeFactory보다는 ShapeFactory(인터페이스)와 ShapeFactoryImp(구현)가 더 좋다.

인터페이스임을 굳이 드러낼 필요는 없다.

 

※ 결론적으로, 현대 프로그래밍 환경에서는 대부분의 인코딩이 불필요하며, 코드의 가독성을 해치는 요소가 된다.

대신 의미 있고 명확한 이름을 사용하는 것이 좋다.

---

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

독자가 코드를 읽으면서 변수 이름을 자신이 아는 이름으로 변환해야 한다면, 그 변수 이름은 바람직하지 못하다.

이는 보통 문제 영역이나 해법 영역에서 흔히 사용하지 않는 이름을 선택했을 때 발생하는 문제다.

 

문자 하나만 사용하는 변수 이름은 대부분 문제가 있다. 단, 예외가 있다:

• 루프에서 반복 횟수를 세는 변수 i, j, k는 허용된다
• 하지만 이는 루프 범위가 아주 작고 다른 이름과 충돌하지 않을 때만 가능하다
• 그 외에는 한 글자 변수를 사용하지 않는다

최악의 경우는 "이미 a와 b를 사용했으니 c를 쓰자"라는 안일한 생각이다.

 

프로그래머들은 보통 매우 똑똑하여 자신의 지적 능력을 과시하고 싶어 한다.

• 예를 들어 'r'이라는 변수가 '호스트와 프로토콜을 제외한 소문자 URI'라는 복잡한 개념을 담고 있다면, 이를 항상 기억하는 것은 분명 뛰어난 능력이다.

하지만 전문가 프로그래머는 명료함이 가장 중요하다는 사실을 이해한다.

• 자신의 능력을 과시하는 대신, 다른 사람들이 쉽게 이해할 수 있는 코드를 작성하는 데 집중한다.

 

※ 결론적으로, 좋은 코드는 읽는 사람이 추가적인 정신적 변환 작업 없이도 즉시 이해할 수 있어야 한다.

---

클래스 이름 짓기

클래스와 객체 이름은 명사나 명사구로 짓는 것이 적절하다.

• 좋은 예: Customer, WikiPage, Account, AddressParser
• 피해야 할 예: Manager, Processor, Data, Info

그리고 동사는 사용하지 않는다

---

메서드 이름

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

• postPayment
• deletePage
• save

자바빈 표준에 따라 접근자, 변경자, 조건자 앞에는 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로 선언한다.

---

기발한 이름은 피하라

기발한 이름은 해당 코드를 이해하는 데 방해가 된다.

같은 유머 감각을 가진 사람만이, 그것도 농담을 기억하는 동안에만 그 의미를 알 수 있기 때문이다.

 

나쁜 예제

• HolyHandGrenade()
  • 무슨 기능인지 알기 어렵다
  • 대신 deleteItems()를 사용하라

피해야 할 사례

• kill() 대신 whack() 사용
• abort() 대신 eatMyShorts() 사용
• 구어체나 속어를 이름으로 사용
• 특정 문화에서만 통용되는 농담

의도를 분명하고 솔직하게 표현하라

---

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

추상적인 개념에는 하나의 단어를 선택하고 이를 일관되게 사용해야 한다.

나쁜 예:

• 같은 동작을 하는 메서드를 클래스마다 다르게 명명
  • fetch
  • retrieve
  • get
• 이런 경우 프로그래머는 각 클래스에서 어떤 이름을 사용했는지 기억해야 하는 불필요한 부담을 안게 된다.

manager, controller, driver를 혼용하면 혼란이 생긴다

• DeviceManager와 ProtocolController의 차이는 무엇인가?
• 왜 둘 다 Controller가 아닌가?
• 왜 둘 다 Manager가 아닌가?
• 이름이 다르면 독자는 당연히 클래스도 다르고 타입이 다르리라 생각한다.

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

---

말장난을 하지 마라

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

프로그래머는 코드를 최대한 이해하기 쉽게 짜야 한다.

집중적인 탐구가 필요한 코드가 아니라 대충 훑어봐도 이해할 코드 작성이 목표다.

---

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

코드를 읽을 사람은 프로그래머라는 점을 기억해야 한다.

따라서 다음과 같은 용어를 사용해도 괜찮다

 

• 전산 용어
• 알고리즘 이름
• 패턴 이름
• 수학 용어

모든 이름을 문제 영역에서 가져오는 정책은 현명하기 못하다

• 같은 개념을 다른 이름으로 이해하던 동료들이 매번 고객에게 의미를 물어야 하기 때문이다

프로그래머에게 익숙한 기술 개념은 아주 많다. 기술 개념에는 기술 이름이 가장 적합한 선택이다.

---

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

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

• 그러면 코드를 유지 보수하는 프로그래머가 필요할 때 분야 전문가에게 의미를 물어볼 수 있다

우수한 프로그래머와 설계자라면 해법 영역(프로그래밍 영역)과 문제 영역(비즈니스 영역)을 명확히 구분할 줄 알아야 한다

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

---

의미 있는 맥락을 추가하라

대부분의 이름은 스스로 의미를 명확히 전달하지 못한다.

• 따라서 클래스, 함수, 이름 공간을 활용해 맥락을 부여해야 한다. 모든 방법이 실패하면 마지막 수단으로 접두어를 붙인다

예를 들어 firstName, lastName, street, houseNumber, city, state, zipcode라는 변수가 있다.

이 변수 '전체' 훑어보면 주소라는 사실을 금방 알아챌 수 있다.

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

그래서 addr라는 접두어를 추가해 addrFirstName, addrLastName, addrState라 쓰면 맥락이 좀 더 분명해질 수 있다.

변수가 좀 더 큰 구조에 속한다는 사실이 적어도 독자에게는 분명해지는 것이다. 

 

아래 코드를 한번 보자.

변수에 좀 더 의미 있는 맥락이 필요할까? 

함수 이름은 맥락 일부만 제공하고, 알고리즘이 나머지 맥락을 제공하고 있다.

함수 전체를 읽은 후에 number, verb, pluralModifier라는 변수 3개가 guess statistics 메시지에 사용된다는 사실이 드러난다.

불행히도 코드를 읽는 프로그래머가 맥락을 유추해야만 하고, 그냥 메서드만 봤을 땐 세 변수의 의미가 불분명하다.

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

 

그리고 함수가 좀 길고, 세 변수를 함수 전반에서 사용하고 있다. 
그래서 아래와 같이 함수를 작은 조각으로 쪼개고자 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에 속한다.

그리고 함수를 쪼개기가 쉬워지면서 알고리즘도 좀 더 명확해졌다.

---

불필요한 맥락을 없애라

일반적으로 짧은 이름이 긴 이름보다 좋다. 

단, 의미가 분명한 경우에 한해서다.
이름에 불필요한 맥락을 추가하지 않도록 주의한다.

• 예를 들어, Address는 클래스 이름으로 적합하다.
• 포트 주소, MAC 주소, 웹 주소를 구분해야 한다면 PastalAdderss, MAC, URI라는 이름도 괜찮다.
• 그러면 의미가 더 분명해진다.

---

마치면서

좋은 이름을 선택하는 것

• 뛰어난 설명 능력이 필요하다
• 같은 문화적 배경이 필요하다

좋은 이름을 선택하는 능력은 단순한 기술이나 비즈니스 문제가 아닌 교육의 문제다

 

어느 코드 개선 노력과 마찬가지로 이름 역시 나름대로 바꿨다가 누군가 질책할지도 모른다.

그렇다고 코드를 개선하려는 노력을 멈추면 안 된다.

 

다른 개발자가 구현한 코드를 리팩토링 한다면 문제 해결 목적으로 이름을 개선하는 것이 좋다.
그렇게 하면 단기적인 효과는 물론 장기적인 이익도 보장한다!

---

글쓴이의 생각

이번 장은 내용이 생각보다 많았다.
그만큼 의미 있는 이름을 짓는다는 게 쉽지 않다는 의미인 것 같다.
아마 내용을 요약하자면 이름을 남들이 봐도 쉽게 이해할 수 있도록 명확하게 지어야 한다는 것이다.
나도 변수명을 지을 때 나만 알아볼 수 있는 변수명으로 지었던 것 같다.
만약 남들이 봤으면 이 코드를 이해할 수 있었을까 의문이 든다.
이 책의 내용을 정리하면서 좋은 이름이란 무엇일지 연구하며 이름을 잘 지어봐야겠다.