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

본 글은 Robert C. Martin의 Clean Code를 읽고 작성자 마음대로 정리한 글입니다.
책 내에 등장하는 코드는 코틀린으로 변환하였으며, 모든 질문 및 태클 환영합니다!

---

소프트웨어에서 이름은 어디나 쓰인다.

 

이름을 잘 지으면 여러모로 편하다 🙄

---

의도를 분명히 밝혀라

좋은 이름을 지으려면 시간이 걸리지만 좋은 이름으로 절약하는 시간이 훨씬 더 많다.

 

변수나 함수 그리고 클래스 이름에 대해 따로 주석이 필요하다면 의도를 분명히 드러내지 못한 것이다.

 

 

이름 d는 아무 의미도 드러나지 않는다.

경과 시간이나 날짜라는 느낌이 들지 않는다.

측정하려는 값과 단위를 표현하는 이름이 필요하다.

 

 

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

다음 코드는 무엇을 할까?

 

 

복잡한 문장이 없음에도 코드가 하는 일을 짐작하기 어렵다.

문제는 코드의 단순성이 아니라 코드의 함축성이다.

코드 맥락이 코드 자체에 명시적으로 드러나지 않으므로 독자가 다음과 같은 정보를 안다고 가정한다.

1. theList에 무엇이 들었는가?
2. theList에서 0번째 값이 어째서 중요한가?
3. 값 4는 무슨 의미인가?
4. 함수가 반환하는 리스트 list1을 어떻게 사용하는가?

위 코드 샘플엔 이와 같은 정보가 드러나지 않지만 정보 제공은 충분히 가능했었다.

 

지뢰찾기 게임을 만든다고 가정하고 theList를 gameBoard로 바꿔보자.

게임판에서 각 칸은 단순 배열로 표현한다.

배열에서 0번째 값은 칸 상태를 뜻한다.

값 4는 깃발이 꽂힌 상태를 가리킨다.

 

각 개념에 이름만 붙여도 코드가 상당히 나아진다.

 

 

코드의 단순성은 변하지 않았다. 연산자 수와 상수 수, 그리고 들여쓰기 단계는 동일하다.

그럼에도 코드는 더욱 명확해졌다.

 

한 단계 더 앞서, int 배열 대신 칸을 간단한 클래스로 만들고

isFlagged라는 좀 더 명시적인 함수를 사용해 FLAGGED라는 상수를 감춰도 좋다.

그 결과는 다음과 같다.

 

 

단순히 이름만 고쳤는데도 함수가 하는 일을 이해하기 쉬워졌다.

이것이 좋은 이름이 주는 위력이다.

 

---

그릇된 정보를 피하라

프로그래머는 코드에 그릇된 단서를 남겨서는 안 된다.

나름대로 널리 쓰이는 의미가 있는 단어를 다른 의미로 사용해도 안 된다.

 

예를 들어, hp, aix, sco는 유닉스 플랫폼이나 변종을 가리키는 이름이기 때문에,

직각삼각형의 빗변^hypotenuse를 구현할 때는 hp가 훌륭한 약어로 보일지라도 독자에게 그릇된 정보를 제공한다.

 

여러 계정을 그룹으로 묶을 때, 실제 List가 아니라면, accountList라 명명하지 않는다.

프로그래머에게 List란 단어는 특수한 의미이기 때문에, 계정을 담는 컨테이너가 실제 List가 아니라면 프로그래머에게 그릇된 정보를 제공하는 셈이 된다.

_{실제 컨테이너가 List인 경우라도 컨테이너 유형을 이름에 넣지 않는 편이 바람직하다.}

 

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

한 모듈에서 XYZControllerForEfficientHandlingOfStrings라는 이름을 사용하고,

조금 떨어진 모듈에서 XYZControllerForEfficientStorageOfStrings라는 이름을 사용한다면 차이를 구분할 수 없다.

 

유사한 개념은 유사한 표기법을 사용한다. 이것도 정보다.

일관성이 떨어지는 표기법은 그릇된 정보다.

 

최신 IDE는 코드 자동 완성 기능을 제공한다.

이름을 몇 자만 입력한 후 핫키^hotkey 조합을 누르면 후보 목록이 뜬다.

후보 목록에 유사한 개념이 알파벳 순으로 나온다면 그리고 각 개념 차이가 명백히 드러난다면 코드 자동 완성 기능은 굉장히 유용해진다.

 

소문자 L이나 대문자 O 변수를 사용한다면 이름으로 그릇된 정보를 제공하는 끔찍한 예가 된다.

다음 코드에서 보듯, 소문자 L은 숫자 1처럼 보이고 대문자 O는 숫자 0처럼 보인다.

(폰트 상의 문제로 본문의 예제에서는 잘 드러나지 않는다. 책에서 보면 헷갈릴만 하다..)

 

 

폰트를 바꿔 차이를 드러내는 등의 해결책은 문서나 구전으로 미래 개발자 모두에게 알려야 하는 해결책이다.

이름만 바꾸면 문제가 깨끗히 풀린다.

 

---

의미 있게 구분하라

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

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

한쪽 이름을 마음대로 바꾸고픈 유혹에 빠져 철자를 살짝 바꿨다가 나중에 철자 오류를 고치는 순간 컴파일이 불가능한 상황에 빠진다.

 

컴파일러를 통과하더라도 연속된 숫자를 붙이거나 불용어^{noise word}를 추가하는 방식은 적절하지 않다.

이러한 이름들은 그릇된 정보를 제공하는 이름도 아니며, 아무런 정보를 제공하지 못하는 이름일 뿐이다.

다음 코드를 살펴보자.

 

 

함수 인수 이름으로 source와 destination을 사용한다면 코드 읽기가 훨씬 쉬워진다.

 

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

Product라는 클래스가 있다고 가정했을 때, 다른 클래스를 ProductInfo 혹은 ProductData라 부른다면 개념을 구분하지 않은 채 이름만 달리한 경우다.

Info나 Data는 a, an, the와 마찬가지로 의미가 불분명한 불용어다.

 

불용어는 중복이다.

변수 이름에 variable, 표 이름에 table이라는 단어는 금물이다.

 

 

코드만 보고서는 어느 함수를 호출할지 알 수 없다.

 

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

 

---

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

사람들은 단어에 능숙하다.

두뇌에서 상당 부분은 단어라는 개념만 전적으로 처리하며, 정의상으로 단어는 발음이 가능하다.

그러므로 발음하기 쉬운 이름을 선택한다.

 

genymdhms^{generate date, year, month, day, hour, minute, second}라는 단어는 어떻게 발음해야 하는가?

(원문에서 저자는 젠 야 무다 힘즈라고 발음했다.)

 

다음 두 예제를 비교해보자.

 

와

 

 

둘째 코드는 지적인 대화가 가능해진다.

 

---

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

문자 하나를 사용하는 이름과 상수는 텍스트 코드에서 쉽게 눈에 띄지 않는다는 문제점이 있다.

 

MAX_CLASSES_PER_STUDENT는 grep으로 찾기가 쉽지만, 숫자 7은 그렇지 않다.

7이 들어가는 파일 이름이나 수식이 모두 검색되기 때문이다. 혹은 7을 사용한 의도가 다른 경우도 있다.

 

마찬가지로 e라는 문자도 변수 이름으로 적합하지 못하다.

e는 영어에서 가장 많이 쓰이는 문자로 거의 모든 프로그램과 문장에 등장한다.

이런 관점에서 긴 이름이 짧은 이름보다 좋고, 검색하기 쉬운 이름이 상수보다 좋다.

 

이름 길이는 범위 크기에 비례해야 한다.

변수나 상수를 코드 여러 곳에서 사용한다면 검색하기 쉬운 이름이 바람직하다.

다음 두 예제를 비교해보자.

 

와

 

 

위 코드에서 sum이 별로 유용하진 않지만 최소한 검색이 가능하다.

이름을 의미 있게 지으면 함수가 길어진다.

하지만 WORK_DAYS_PER_WEEK는 찾기가 쉬워진다.

그냥 5를 사용한다면 5가 들어가는 이름을 모두 찾은 후 의미를 분석해 원하는 상수를 가려내야 한다.

 

---

인코딩을 피하라

굳이 부담을 더하지 않아도 이름에 인코딩할 정보는 아주 많다.

유형이나 범위 정보까지 인코딩에 넣으면 그만큼 이름을 해독하기 어려워진다.

인코딩한 이름은 거의가 발음하기 어려우며 오타가 생기기도 쉽다.

 

헝가리식 표기법

이름 길이가 제한된 언어를 사용하던 옛날에 어쩔 수 없이 위반하던 규칙이다.

포트란은 첫 글자로 유형을 표현했다.

초창기 베이식은 글자 하나에 숫자 하나만 허용했다.

당시에는 컴파일러가 타입을 점검하지 않았으므로 프로그래머에게 타입을 기억할 단서가 필요했다.

 

그러나 현대 IDE는 코드를 컴파일하지 않고도 타입 오류를 감지할 정도로 발전했다.

따라서 이제는 헝가리식 표기법이나 기타 인코딩 방식이 오히려 방해가 된다.

 

 

멤버 변수 접두어

멤버 변수에 m_이라는 접두어를 붙일 필요도 없다.

클래스와 함수는 접두어가 필요없을 정도로 작아야한다.

 

 

코틀린으로는 getter / setter를 따로 둘 필요가 없다.

책의 내용을 좀 더 따라가기 위해 setter를 명시적으로 두었다.

 

코드를 읽을수록 접두어는 관심 밖으로 밀려난다.

 

 

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

때로는 인코딩이 필요한 경우도 있다.

 

예를 들어, 도형을 생성하는 ABSTRACT FACTORY를 구현한다고 가정하자.

이 팩토리는 인터페이스 클래스^{interface class}이며 구현은 구체 클래스^{concrete class}에서 한다.

 

옛날 코드에서 많이 사용하는 접두어 I는 (잘해봤자) 주의를 흐트리고 (나쁘게는) 과도한 정보를 제공한다.

 

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

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

 

ShapeFactoryImp나 CShapeFactory가 IShapeFactory보다 좋다.

 

---

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

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

이는 일반적으로 문제 영역이나 해법 영역에서 사용하지 않는 이름을 선택했기 때문에 생기는 문제다.

 

문자 하나만 사용하는 변수 이름은 문제가 있다.

루프에서 반복 횟수를 세는 변수 i, j, k 는 괜찮다. ( l은 절대 안된다!)

루프 범위가 아주 작고 다른 이름과 충돌하지 않을 때만 괜찮다.

그 외에는 독자가 실제 개념으로 변환해야 하니 대부분 적절하지 못하다.

 

똑똑한 프로그래머와 전문가 프로그래머 사이에서 나타나는 차이점 중 하나는,

전문가 프로그래머는 명료함이 최고라는 사실을 이해한다는 것이다.

 

전문가 프로그래머는 자신의 능력을 좋은 방향으로 사용해 남들이 이해하는 코드를 내놓는다.

 

---

클래스 이름

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

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

 

---

메서드 이름

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

postPayment, deletePage, save 등이 좋은 예다.

접근자^Accessor, 변경자^Mutator, 조건자^Predicate는 javabean 표준에 따라 값 앞에 get, set, is를 붙인다.

(코틀린에서는 getter, setter 등을 property access syntac로 제공한다.)

 

 

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

메서드는 인수를 설명하는 이름을 사용한다.

예를 들어, 다음 두 예제를 살펴보자.

 

 

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

 

 

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

 

---

기발한 이름은 피하라

이름이 너무 기발하면 저자와 유머 감각이 비슷한 사람만, 그리고 농담을 기억하는 동안만, 이름을 기억한다.

HiolyHandGrenade라는 함수는 기발한 이름이지만 DeleteItems가 더 좋다.

 

재미난 이름보다 명료한 이름을 선택하라.

 

구어체나 속어 등 특정 문화에서만 사용하는 농담은 피하는 편이 좋다.

 

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

 

---

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

추상적인 개념 하나에 단어 하나를 선택해 이를 고수한다.

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

 

최신 IDE는 문맥에 맞는 단서를 제공한다.

예를 들어, 객체를 사용하면 그 객체가 제공하는 메서드 목록을 보여준다.

하지만 목록은 보통 함수 이름과 매개변수만 보여줄 뿐 주석은 보여주지 않는다.

(안드로이드 스튜디오는 매개변수 이름 + javadoc까지 다 보여주는데..)

따라서 메서드 이름은 독자적이고 일관적이여야 한다.

주석을 뒤져보지 않고도 프로그래머가 올바른 메서드를 선택할 수 있어야 한다.

 

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

 

---

말장난을 하지 마라

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

다른 개념에 같은 단어를 사용한다면 말장난에 불과하다.

 

프로그래머가 같은 맥락이 아닌데도 '일관성'을 고려해 add라는 단어를 선택하는 경우도 있다.

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

새로 작성하는 메서드는 집합에 값 하나를 추가할 때, 기존 add 메서드와 맥락이 다르다.

그러므로 insert나 append라는 이름이 적당하다.

 

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

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

 

---

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

코드를 읽을 사람도 프로그래머라는 사실을 명심한다.

그러므로 전산 용어, 알고리즘 이름, 패턴 이름, 수학 용어 등을 사용해도 괜찮다.

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

 

JobQueue와 같이 프로그래머에게 익숙한 기술 개념은 아주 많다.

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

 

---

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

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

그러면 코드를 보수하는 프로그래머가 분야 전문가에게 의미를 물어 파악할 수 있다.

 

해법 영역과 문제 영역을 구분하여 문제 영역 개념과 관련이 깊은 코드라면 문제 영역에서 이름을 가져와야 한다.

 

---

의미 있는 맥락을 추가하라

스스로 의미가 분명한 이름이 없지 않다.

하지만 대다수 이름은 그렇지 못하다.

그래서 클래스, 함수, 이름 공간에 넣어 맥락을 부여한다.

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

 

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

변수를 훑어보면 주소라는 사실을 알아챌 수 있지만,

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

 

addr라는 접두어를 추가해 addrFirstName, addrLastName, addtState라 쓰면 맥락이 좀 더 분명해진다.

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

물론 Address라는 클래스를 생성하면 더 좋다.

 

아래 예시를 살펴보자. 함수 이름은 맥락 일부만 제공하며, 알고리즘이 나머지 맥락을 제공한다.

함수를 끝까지 읽어보고 나서야 number, verb, pluralModifier라는 변수 세 개가 '통계 추측^{guess statistics}' 메시지에 사용된다는 사실이 드러난다.

그냥 메서드만 훑어서는 세 변수의 의미가 불분명하다.

 

 

일단 함수가 좀 길고, 세 변수를 함수 전반에서 사용한다.

함수를 작은 조각으로 쪼개고자 GuessStatisticsMessage라는 클래스를 만든 후 세 변수를 클래스에 넣는다.

그러면 세 변수는 맥락이 분명해진다.

즉, 세 변수는 확실하게 GuessStatisticsMessage에 속한다.

이렇게 맥락을 개선하면 함수를 쪼개기가 쉬워지므로 알고리즘도 좀 더 명확해진다.

 

 

---

불필요한 맥락을 없애라

'고급 휘발유 충전소^{Gas Station Deluxe}'라는 애플리케이션을 짠다고 가정하자.

모든 클래스 이름을 GSD로 시작한다는 생각은 전혀 바람직하지 못하다.

IDE에서 G를 입력하고 자동 완성 키를 누르면 IDE는 모든 클래스를 열거한다.

IDE를 방해하는 격이 된다.

 

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

단, 의미가 분명한 경우에 한해서다.

이름에 불필요한 맥락을 추가하지 않도록 주의한다.

 

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

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

포트 주소, MAC 주소, 웹 주소를 구분해야 한다면 PostalAddress, MAC, URI라는 이름도 괜찮겠다.

그러면 의미가 좀 더 분명해진다.

바로 이것이 이름을 붙이는 이유겠다.

 

---

마치면서

좋은 이름을 선택하려면 설명 능력이 뛰어나야 하고 문화적인 배경이 같아야 한다.

이것이 제일 어렵다.

 

좋은 이름으로 바꾸어 코드를 개선하려는 노력을 중단해서는 안된다.