2장 의미 있는 이름

소프트웨어에서 이름은 어디에서나 사용된다. 변수에도 이름을 붙이고, 함수에도 이름을 붙이고, 인수와 클래스, 패키지에도 이름을 붙인다. 소스 파일에도 이름을 붙이고, 소스 파일이 담긴 디렉터리에도 이름을 붙인다. 이처럼 많은 부분에서 이름을 사용하는데, 이때 이름을 잘 지으면 여러모로 편하다. 이번 장에서는 이름을 잘 지을 수 있는 간단한 규칙 몇 가지를 소개한다.

 

의도를 분명히 밝혀라

코드를 단순하게 작성한다고 좋은 코드라고 말할 수 없다. 단순하게 작성했더라도 코드 맥락이 코드 자체에 명시적으로 드러나지 않는다면, 해당 코드를 어떤 의도로 작성했는지 또는 하는 일이 무엇인지 이해하기란 쉽지 않을 것이다. 이때 코드의 의미를 부여할 수 있는 것이 바로 이름이다. 의도가 분명하게 드러나는 이름을 사용한 코드는 이해와 변경이 쉽다. 그러므로 이름을 주의 깊게 살펴 더 나은 이름으로 개선하는 것이 자신을 포함해 코드를 읽는 사람으로 하여금 편안함을 제공할 수 있다.

 

그릇된 정보를 피하라

프로그래머는 코드에 그릇된 단서를 남겨서는 안 된다. 이는 코드의 의미를 흐리게 된다. 나름대로 널리 쓰이는 의미가 있는 단어를 다른 의미로 사용해도 안된다. 예를 들어 직각 삼각형의 빗변(hypotenuse)을 구현할 때 hp가 훌륭한 약어로 보일지라도 hp라는 변수는 읽는 사람들로 하여금 잘못된 정보를 제공할 수 있다. 그리고 여러 계정을 그룹을 묶을 때, 실제 List가 아니라면, accountList라고 이름 짓지 않는 것이 좋다. 이는 계정을 담는 컨테이너가 실제 List가 아니라면 프로그래머에게 잘못된 정보를 제공할 수 있기 때문에 accountGroup, bunchOfAccounts, 아니면 단순히 Accounts라고 짓는 것이 좋다.
서로 비슷한 이름을 사용하지 않도록 주의해야 한다. 비슷한 이름을 사용하게 된다면 읽는 사람이 그 차이를 알기란 쉽지 않다. 그리고 유사한 개념은 유사한 표기법을 사용하는 것이 좋다. (이것도 하나의 정보가 될 수 있는데, 일관성이 떨어지는 표기법은 잘못된 정보를 전달할 수 있다.) 이름으로 잘못된 정보를 제공하는 예가 L과 O를 변수로 사용하는 것이다. 소문자 L은 숫자 1처럼 보이고, O는 숫자 0처럼 보이게 된다.

 

의미 있게 구분하라

연속된 숫자를 덧붙이거나 불용어(noise word)를 추가하는 방식은 적절하지 못하다. 이름이 달라야 한다면 의미도 달라져야 한다. 연속적인 숫자를 덧붙인 이름(a1, a2,... aN)은 의도적인 이름과는 정반대다. 이런 이름은 잘못된 정보를 제공하는 이름도 아니며, 아무런 정보를 제공하지 못하는 이름이다. (저자의 의도가 전혀 드러나지 않는다.)
불용어를 추가한 이름 역시 아무런 정보도 제공하지 못한다. Product라는 클래스가 있다고 가정해보자. 다른 클래스를 ProductInfo 또는 ProductData라고 부른다면 개념을 구분하지 않은 채 이름만 달리 한 경우다. (Info나 Data는 의미가 불분명한 불용어다.) 변수 이름에 variable이라는 단어를 붙이거나 표 이름에 table이라는 이름을 붙이는 것은 안된다. 읽는 사람이 차이를 알도록 이름을 지어야 한다.

 

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

발음하기 쉬운 이름은 중요하다. 이는 프로그래밍은 사회활동이기 때문이다. 작성한 코드에 대해 회의를 하는 등의 커뮤니케이션이 이루어질 때, 발음이 어렵다면 방해가 될 수 있다.

 

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

문자 하나를 사용하는 이름과 상수는 텍스트 코드에서 쉽게 눈에 띄지 않는다는 문제점이 있다. MAX_CLASSES_PER_STUDENT는 grep으로 찾기가 쉽지만, 알파벳 'e'는 찾기가 까다롭다. 'e'는 영어에서 가장 많이 쓰이는 문자이기 때문에 거의 모든 문장에서 등장하기 때문에 'e'를 grep 하면 거의 모든 단어가 검색되어 내가 원하는 부분을 찾기 어렵다. 이런 관점에서 긴 이름이 짧은 이름보다 좋고, 검색하기 쉬운 이름이 하나의 문자 또는 상수보다 좋다.

let realDaysPerIdealDay = 4;
const WORK_DAYS_PER_WEEK = 5;
let sum = 0;
for(let i = 0; i < NUMBER_OF_TASKS; i++) {
  let realTaskDays = taskEstimate[i] * realDaysPerIdealDay;
  sum += realTaskDays;
}

위 코드에서 sum이 별로 유용하지 않으나 최소한 검색이 가능하다. 그리고 WORK_DAYS_PER_WEEK이라는 변수 이름의 길이는 길지만 찾기가 쉽고, 그 의미가 명확하기 때문에 코드를 이해하기 쉽다.

 

인코딩을 피하라

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

 

헝가리식 표기법

헝가리식 표기법은 프로그래밍 언어에서 변수 및 함수의 인자 이름 앞에 데이터 타입을 명시하는 코딩 규칙이다. 예를 들어 byte나 boolan 타입에는 b를, Array(배열) 타입은 arr를, String(문자열) 타입은 str을 붙여 타입을 명시한다. 과거에는 컴파일러가 타입을 점검하지 않았으므로 프로그래머에게 타입을 기억할 단서가 필요했기 때문에 변수 및 함수의 인자 앞에 데이터 타입을 명시하였다. 하지만 IDE가 발전함에 따라 코드를 컴파일하지 않고도 타입 오류를 감지할 정도로 발전했다. 따라서 이제는 헝가리식 표현법이나 기타 인코딩 방식이 변수나 함수, 클래스의 이름이나 타입을 바꾸기가 어려워지며, 가독성도 떨어뜨린다.

 

멤버 변수 접두어

이제는 멤버 변수에 m_이라는 접두어를 붙일 필요가 없다. 클래스와 함수는 접두어가 필요 없을 정도로 작아야 한다. 접두어는 옛날에 작성한 구닥다리 코드가 되었다.

 

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

인터페이스 이름에 접두어를 붙이지 않는 편이 좋다. 인터페이스 클래스 이름과 구현 클래스 이름 중 하나를 인코딩해야 한다면 구현 클래스 이름이 훨씬 좋다.

 

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

코드를 읽으면서 변수 이름을 자신이 아는 이름으로 변환해야 한다면 그 변수 이름은 바람직하지 못하다. 똑똑한 프로그래머와 전문가 프로그래머 사이에서 나타나는 차이는 전문가 프로그래머는 명료함이 최고라는 사실을 이해한다는 점이다. 전문가 프로그래머는 자신의 능력을 좋은 방향으로 사용해 남들이 이해하는 코드를 내놓는다.

 

클래스 이름

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

 

메서드 이름

메서드 이름은 동사나 동사구가 적합하다. postPayment, deletePage, save 등이 좋은 예이다. 접근자, 변경자, 조건자에 따라 값 앞에 get, set, is를 붙인다. 그리고 생성자를 중복 정의할 때는 정적 팩도리 메서드를 사용한다.

 

기발한 이름은 피하라

재미난 이름보다는 명료한 이름을 선택해야 한다. 간혹 프로그래머가 나름대로 재치를 발휘해 이름을 작성하는 경우가 있는데, 특정 문화에서만 사용하는 농담은 피하는 편이 좋고, 의도를 분명하고 솔직하게 표현하는 것이 좋다.

 

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

추상적인 개념 하나에 단어 하나를 선택해 이를 고수하는 것이 좋다. 메서드 이름은 독자적이고 일관적이어야 프로그래머로 하여금 주석을 뒤져보지 않고도 올바른 메서드를 선택할 수 있게 해 준다.

 

말장난을 하지 마라

한 단어를 두 가지 목적으로 사용하지 말아야 한다. 다른 개념에 같은 단어를 사용한다는 것은 말장난에 불과하다. 예를 들어 지금까지 구현한 add 메서드는 모두 기존 값 두 개를 더하거나 이어서 새로운 값을 만든다고 가정해보자. 집합에 값을 추가하는 메서드를 새로 작성한다고 해서 해당 메서드에 add를 사용하는 것은 기존에 작성한 add과는 맥락이 다르므로 일관성을 무너뜨리는 행위이다. add를 사용하기보다는 insert나 append로 이름을 짓는 것이 적당하다.

프로그래머는 코드를 최대한 이해하기 쉽게 짜야한다. 집중적인 탐구가 필요한 코드가 아니라 대충 훑어봐도 이해할 수 있는 코드를 작성하는 것을 목표로 해야 한다.

 

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

코드를 읽을 사람도 프로그래머이기 때문에 전산 용어, 알고리즘 이름, 패턴 이름, 수학 용어 등을 사용해도 괜찮다.

 

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

적절한 '프로그래머 용어'가 없다면 문제 영역에서 이름을 가져온다. 우수한 프로그래머와 설계자라면 해법 영역과 문제 영역을 구분할 줄 알아야 한다. 문제 영역 개념과 관련이 깊은 코드라면 문제 영역에서 이름을 가져와야 한다.

 

의미 있는 맥락을 추가하라

firstName, lastName, street, houseNumber, city, state, zipcode라는 변수가 있다고 해보자. 변수를 훑어보면 주소라는 사실을 금방 알 수 있다. 하지만 어느 메서드가 state라는 변수 하나만을 사용한다면? 변수 state이 주소의 일부분이라는 것을 알기는 쉽지 않을 것이다. 여기에 addr이라는 접두어를 추가해서 addFirstName, addrLastName, addrState라고 쓰면 맥락이 좀 더 분명해진다. (물론 Address라는 클래스를 생성하면 더 좋다.)

 

불필요한 맥락을 없애라

고급 휘발유 충전소(Gas Station Deluxe)라는 애플리케이션을 개발한다고 할 때, 모든 클래스 이름을 GSD로 시작하는 것은 바람직하지 못하다. 일반적으로 짧은 이름이 긴 이름보다 좋다. 단, 의미가 분명한 경우에 한해서다. 이름에 불필요한 맥락을 추가하지 않도록 주의해야 한다.

 

 

대다수의 사람들이 자신이 짠 클래스 이름과 메서드 이름을 모두 암기하지 못한다. 암기는 요즘 나오는 도구에게 맡기고, 우리는 문장이나 문단처럼 읽히는 코드 아니면 적어도 표나 자료 구조처럼 읽히는 코드를 짜는데 집중하는 것이 마땅하다.