[CleanCode] 2장. 의미있는 이름

이름은 많이 사용하므로 잘 지으면 여러모로 편하다.

의도를 분명히 밝혀라

의도가 분명하게 이름을 지어라.
좋은 이름을 지으려면 시간이 걸리지만 좋은 이름으로 절약하는 시간이 훨씬 많다. 그러므로 이름을 주의 깊게 살펴 더 나은 이름이 떠오르면 개선하기 바란다.
변수나 함수, 클래스 이름은 다음의 질문에 답해야 한다.
- 변수, 함수, 클래스의 존재 이유는?
- 수행 기능은?
- 사용 방법은?
따로 주석이 필요하다면 의도를 분명히 드러내지 못했다는 말이다.

int d; // 경과 시간(단위 : 날짜)
// 아무 의미도 드러나지 않는다. 경과 시간이나 날짜라는 느낌이 안 든다.

int daysSinceCreation;
int fildAgeInDays;
// 의도가 드러나는 이름을 사용한다. 그러므로 코드 이해와 변경이 쉬워진다.

이름만 고쳐도 함수가 하는 일, 코드의 의미를 이해하기 쉬워진다.

그릇된 정보를 피하라

프로그래머는 코드에 그릇된 단서를 남겨서는 안된다. 이는 코드 의미를 흐린다.
나름대로 널리 쓰이는 의미가 있는 단어를 다른 의미로 사용해도 안된다.
ex) hp, iax, sco는 변수 이름으로 적합하지 않다. 이유는 유닉스 플랫폼이나 유닉스 변종을 가리키는 이름이기 때문이다.
여러 계정을 그룹으로 묶을 때, 실제 List가 아니라면 accountList라 명명하지 않는다. 계정을 담는 컨테이너가 실제 List가 아니라면 프로그래머에게 그릇된 정보를 제공하는 셈이다. 그러므로 accountGroup, bunchOfAccounts 아니면 Accounts라 명명한다.
서로 흡사한 이름을 사용하지 않도록 주의한다.
유사한 개념은 유사한 표기법을 사용한다. 이것도 정보다. 일관성이 떨어지는 표기법은 그릇된 정보다.
이름으로 그릇된 정보를 제공하는 끔찍한 예는 소문자 L이나 대문자 O 변수다. 절대 쓰지 말자!

의미있게 구분하라

동일한 범위 안에서 다른 두 개념에 같은 이름을 사용하지 못한다.
컴파일러를 통과할지라도 연속된 숫자를 덧붙이거나 불용어를 추가하는 것은 적절하지 못하다. 이름이 달라야 한다면 의도도 달라져야 한다.
연속적인 숫자를 덧붙인 이름(a1, a2, …, aN)은 의도적인 이름과 정반대다. 그릇된 정보를 제공하는 것이 아니라 아무런 정보도 제공하지 못하는 이름이다.
불용어를 추가한 이름 역시 아무런 정보도 제공하지 못한다. Product라는 클래스가 있고, 다른 클래스를 ProductInfo, ProductData라 부른다면 개념을 구분하지 않은 채 이름만 달리한 경우다.
moneyAmount는 money와 구분이 안된다. 이처럼 읽는 사람이 차이를 알도록 이름을 지어라.

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

사람들은 단어에 능숙하며, 우리 두뇌에서 상단 부분은 단어라는 개념만 전적으로 처리한다. 그리고 정의상으로 단어는 발음이 가능하다. 따라서 발음하기 쉬운 이름을 선택한다. 발음하기 어려운 이름은 토론하기도 어렵다.
ex) 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";
}

위의 두 코드를 보면 지적인 대화가 가능한 것은 두 번째 코드이다. 따라서 발음하기 쉬운 이름은 의사소통에 영향을 미친다.

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

문자 하나를 사용하는 이름과 상수는 텍스트 코드에서 쉽게 눈에 띄지 않는다음 문제점이 있다.
숫자 7은 찾기 까다롭다. 7이 들어가는 파일 이름이나 수식이 모두 검색되기 때문이다. 또한, 7을 사용한 의도가 다른 경우도 있다.
e라는 문자도 변수 이름으로 적합하지 못하다. e는 영어에서 많이 쓰이며, 프로그램의 거의 모든 문장에 등장한다. 이런 관점에서 긴 이름이 짧은 이름보다 좋다.
검색하기 쉬운 이름이 상수보다 좋다.

for(int j=0; j< 32; 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를 찾기가 훨씬 쉽다.

인코딩을 피하라

유형이나 범위 정보까지 인코딩에 넣으면 그만큼 이름을 해독하기 어려워진다.
문제 해결에 집중하는 개발자에게 인코딩은 불필요한 정신적 부담이다.

헝가리식 표기법

모든 변수가 정수 핸들, long 포인터, void 포인터, (속성과 용도가 다른) 여러 ‘문자열’ 중 하나였다. 당시는 컴파일러가 타입을 점검하지 않았으므로 프로그래머에게 타입을 기억할 단서가 필요했다.
요즘은 IDE가 코드를 컴파일하지 않고도 타입 오류를 감지한다. 딸서 헝가리식 표기법이나 기타 인코딩 방식이 오히려 방해가 된다.

멤버 변수 접두어

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

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

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

인터페이스 이름은 접두어를 붙이지 않는 편이 좋다.
접두어 I는 주의를 흐트리고 나쁘게는 과도한 정보를 제공한다.
내가 다루는 클래스가 인터페이스라는 사실을 남에게 알리고 싶지 않다. 클래스 사용자는 그냥 ShapeFactory 라고만 생각하면 좋겠다.
그래서 인터페이스 클래스 이름과 구현 클래스 이름 중 하나를 인코딩 해야 한다면 구현 클래스 이름을 택하겠다. ShapeFactoryImpl나 심지어 CShapeFactory가 IShapeFactory보다 좋다.

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

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

클래스 이름

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

메소드 이름

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

string name = employee.getName();
customer.setName("Lee");
if(paycheck.isPosted()){
    ...
}

생성자를 오버로딩할 때는 정적 팩토리 메소드를 사용한다.
메소드는 인수를 설명하는 이름을 사용한다.

1
2
3

Complex flucrumPoint = Complex.FromRealNumber(23.0); // 1

Complex flucrumPoint = new Complex(23.0); // 2

1번 코드가 2번보다 좋다.
생성자 사용을 제한하려면 해당 생성자를 private으로 선언한다.

기발한 이름은 피하라

재미난 이름보다 명료한 이름을 선택하라.
구어체나 속어를 사용하는 것도 피해야 한다. 예를 들어, kill() 대신 whack()를 사용한다거나, Abort() 대신 eatMyShort()라 부르는 것처럼 특정 문화에서만 사용하는 농담은 피하는 편이 좋다.
의도를 분명하고 솔직하게 표현하라.

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

추상적인 개념 하나에 단어 하나를 선택해 이를 고수한다.
ex) 똑같은 메소드를 클래스마다 fetch, retrieve, get으로 제각각 부르면 혼란스럽다.
마찬가지로 동일 코드 기반에 controller, manager, driver를 섞어 쓰면 혼란스럽다. DeviceManager와 ProtocolController는 근본적으로 어떻게 다른가? 어째서 둘 다 Controller가 아닌가? 어째서 둘 다 Manager가 아닌가? 이름이 다르면 독자는 당연히 클래스도 다르고 타입도 다르다고 생각한다.
일관성 있는 어휘는 코드를 사용할 프로그래머가 반갑게 여길 선물이다.

말장난을 하지 마라

한 단어를 두 가지 목적으로 사용하지 마라. 다른 개념에 같은 단어를 사용한다면 그것은 말장난에 불과하다.
프로그래머는 코드를 최대한 이해하기 쉽게 짜야 한다. 집중적인 탐구가 필요한 코드가 아니라 대충 훑어봐도 이해할 코드 작성이 목표다.
ex) 지금까지 구현한 add 메소드는 모두 기존 값 두개를 더하거나 이어서 새로운 값을 만든다고 가정하자. 새로 작성하는 메소드는 집합에 값 하나를 추가한다. 이 메소드를 add라 불러도 괜찮을까? add라는 메소드가 많으므로 일관성을 지키려면 add라 불러야 하지 않을까? 하지만 새 메소드는 기존 add 메소드와 맥락이 다르다 그러므로 insert나 append라는 이름이 적당하다. 새 메소드를 add라 부른다면 이는 말장난이다.
의미를 해독할 책임이 있는 독자에게 있는 논문 모델이 아니라 의도를 밝힐 책임이 있는 저자에게 있는 잡지 모델이 바람직하다.

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

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

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

적절한 '프로그래머 용어’가 없다면 문제 영역에서 이름을 가져온다. 그러면 코드를 보수하는 프로그래머가 분야 전문가에게 의미를 물어 파악할 수 있다.

의미 있는 맥락을 추가하라

아래 메소드를 보자. 변수에 좀 더 의미 있는 맥락이 필요할까? 함수 이름은 맥락 일부만 제공하며, 알고리즘이 나머지 맥락을 제공한다.
함수를 끝까지 읽어보고 나서야 number, verb, pluralModifier라는 변수 세 개가 통계 추측 메시지에 사용된다는 사실이 드러난다.
이는 독자가 맥락을 유추해야만 한다. 그냥 메소드만 훑어서는 세 변수의 의미가 불분명하다.

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, pluralModifer);
  print(guessMessage);
}

위의 코드는 함수가 길며 세 변수를 함수 전반에서 사용한다.
함수를 작은 조각으로 쪼개고자 GuessStatisticsMessage라는 클래스를 만든 후, 세 변수를 클래스에 넣는다. 그러면 세 변수는 맥락이 분명해진다. 즉, 세 변수는 확실하게 GuessStatisticsMessage에 속한다.
이렇게 맥락을 개선하면 함수를 쪼개기가 쉬워진다.

public class GuessStatisticsMessage{
    private String number;
    private String verb;
    private String pluralModifier;

    public String maek(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";
    }
}

불필요한 맥락을 없애라

일반적으로 짧은 이름이 긴 이름보다 좋다. 단, 의미가 분명한 경우에 한해서다.
이름에 불필요한 맥락을 추가하지 않도록 주의한다.
accountAddress, customerAddress는 Address 클래스의 인스턴스로는 좋은 이름이나 클래스 이름으로는 적합하지 못하다.
Address는 클래스 이름으로 적합하다.

Reference

Clean Code