우리는 변수에도 이름을 붙이고, 함수에도 이름을 붙이고, 인수와 클래스와 패키지에도 이름을 붙인다. 이 외에도 여기저기 도처에서 이름을 사용한다. 이렇듯 많이 사용하므로 이름을 잘 지으면 여러모로 편하다. 이 장에서는 이름을 잘 짓는 간단한 규칙을 알아본다.
의도를 분명히 밝혀라
좋은 이름을 지으려면 시간이 걸리지만 좋은 이름으로 절약하는 시간이 훨씬 더 많다. 그러므로 이름을 주의 깊게 살펴 더 나은 이름이 떠오르면 개선하자. 그러면 코드를 읽는 사람이 좀 더 행복해질것이다.
의도가 드러나는 이름을 사용하면 코드 이해와 변경이 쉬워진다. 다음 코드는 무엇을 할까??
public List<int[]> getThem() {
List<int[]> list1 = new ArrayList<int[]>();
for (int[] x : theList)
if(x[0] == 4)
list1.add(x);
return list1;복잡한 문장은 없지만 코드가 하는 일을 짐작하기 어렵다. 문제는 코드의 단순성이 아니라 코드의 함축성이다. 코드 맥락이 코드 자체에 명시적으로 드러나지 않는다.
public List<Cell> getFlaggedCells() {
List<Cell> flaggedCells = new ArrayList<Cell>();
for (Cell cell : gameBoard)
if(cell.isFlagged())
flaggedCells.add(cell);
return flaggedCells;단순히 이름만 고쳤는데도 함수가 하는 일을 이해하기 쉬워졌다. 바로 이것이 좋은 이름이 주는 위력이다.
그릇된 정보를 피하라
프로그래머는 코드에 그릇된 단서를 남겨서는 안된다. 그릇된 단서는 코드 의미를 흐린다. 나름대로 널리 쓰이는 의미가 있는 단어를 다른 의미로 사용해도 안된다.
여러 계정을 그룹으로 묶을 때 실제 List가 아니라면, accountList라 명명하지 않는다. accountGroup, bunchOfAccount, Accounts라 명명한다.
서로 흡사한 이름을 사용하지 않도록 주의한다.
의미 있게 구분하라
컴파일러나 인터프리터만 통과하려는 생각으로 코드를 구현하는 프로그래머는 스스로 문제를 일으킨다.
컴파일러를 통과할지라도 연속된 숫자를 덧붙이거나 불용어를 추가하는 방식을 적절하지 못하다. 이름이 달라야한다면 의미도 달라져야 한다.
읽는 사람이 차이를 알도록 이름을 지어라
발음하기 쉬운 이름을 사용하라
발음하기 어려운 이름은 토론하기도 어렵다.발음하기 쉬운 이름은 중요하다. 프로그래밍은 사회 활동이기 때문이다.
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";
/* ... */
};둘째 코드는 지적인 대화가 가능해진다.
검색하기 쉬운 이름을 사용하라
문자 하나를 사용하는 이름과 상수는 텍스트 코드에서 쉽게 눈에 띄지 않는다는 문제점이 있다. 이름을 의미있게 지으면 함수가 길어진다. 하지만 찾기가 얼마나 쉬운지 생각해보라.
인코딩을 피하라
굳이 부담을 더하지 않아도 이름이 인코딩할 정보는 아주 많다. 유형이나 범위 정보까지 인코딩에 넣으면 그만큼 이름을 해독하기 어려워진다.
자신의 기억력을 자랑하지 마라
독자가 코드를 읽으면서 변수 이름을 자신이 아는 이름으로 변환해야 한다면 그 변수 이름은 바람직하지 못하다. 이는 일반적으로 문제 영역이나 해법 영역에서 사용하지 않는 이름을 선택했기 때문에 생기는 문제다.
전문가 프로그래머는 명료함이 최고라는 사실을 이해한다. 전문가 프로그래머는 자신의 능력을 좋은 방향으로 사용해 남들이 이해하는 코드를 내놓는다.
클래스 이름
클래스 이름과 객체 이름은 명사나 명사구가 적합하다. Customer, WikiPage, Account, AddressParser 등이 좋은 예다. Manager, Processor, Data, Info 등과 같은 단어는 피하고, 동사는 사용하지 않는다.
메서드 이름
메서드 이름은 동사나 동사구가 적합하다. postPayment, deletePage, save 등이 적합하다. 접근자, 변경자, 조건자는 javabean표준에 따라 값 앞에 get, set, is를 붙인다.
기발한 이름은 피하라
이름이 너무 기발하면 저자와 유머 감각이 비슷한 사람만, 그리고 농담을 기억하는 동안만 이름을 기억한다. 재미난 이름보다 명료한 이름을 선택하라. 특정 문화에서만 사용하는 농담은 피하는 편이 좋다. 의도를 분명하고 솔직하게 표현하라
한 개념에 한 단어를 사용하라
추상적인 개념 하나에 단어 하나를 선택해 이를 고수한다. 예를 들어, 똑같은 메서드를 클래스마다 fetch, retrieve, get으로 제각각 부르면 혼란스럽다.
이클립스, 인텔리제이 등과 같은 최신 IDE는 문맥에 맞는 단서를 제공한다.
마찬가지로, 동일 코드 기반에 controller, manager, driver를 섞어 쓰면 혼란스럽다. 이름이 다르면 독자는 당연히 클래스도 다르고 타입도 다르리라 생각한다. 일관성 있는 어휘는 코드를 사용할 프로그래머가 반갑게 여길 선물이다.
말장난을 하지 마라
한 단어를 두 가지 목적으로 사용하지 마라. 다른 개념에 같은 단어를 사용한다면 그것은 말장난에 불과하다.
예를 들어, 지금까지 구현한 add 메서드는 모두가 기존 값 두 개를 더하거나 이어서 새로운 값을 만든다고 가정하자. 새로 작성하는 메서드는 집합에 값 하나를 추가한다. 이 메서드를 add라 불러도 괜찮을까? 새 메서드는 기존 add 메서드와 맥락이 다르기 때문에 insert나 append라는 이름이 적당하다. 새 메서드를 add라 부른다면 이는 말장난이다.
프로그래머는 코드를 최대한 이해하기 쉽게 짜야 한다. 집중적인 탐구가 필요한 코드가 아니라 대충 훑어봐도 이해할 코드 작성이 목표다.
해법 영역에서 가져온 이름을 사용하라
코드를 읽을 사람도 프로그래머라는 사실을 명심하자. 그러므로 전산 용어, 알고리즘 이름, 패턴 이름 등을 사용해도 괜찮다. 하지만 모든 이름을 문제 영역에서 가져오는 것은 현명하지 못하다. 같은 개념을 다른 이름으로 이해하던 동료들이 매번 고객에게 의미를 물어야 하기 때문이다.
문제 영역에서 가져온 이름을 사용하라
적절한 프로그래머 용어가 없다면 문제 영역에서 이름을 가져온다. 그러면 코드를 보수하는 프로그래머가 분야 전문가에게 의미를 물어 파악할 수 있다.
우수한 프로그래머와 설계자라면 해법영역과 문제영역을 구분할 줄 알아야한다. 문제영역 개념과 관련이 깊은 코드라면 문제영역에서 이름을 가져와야 한다.
의미 있는 맥락을 추가하라
스스로 의미가 분명한 이름이 없지 않다. 하지만 대다수 이름은 그렇지 못하다. 그래서 클래스, 함수, 이름 공간에 넣어 맥락을 부여한다. 모든 방법이 실패하면 마지막 수단으로 접두어를 붙인다.
불필요한 맥락을 없애라
일반적으로는 짧은 이름이 긴 이름보다 좋다. 단, 의미가 분명한 경우에 한해서다. 이름에 불필요한 맥락을 추가하지 않도록 주의한다.
accountAddress와 customerAddress는 Address 클래스 인스턴스로는 좋은 이름이나 클래스 이름으로는 적절하지 못하다. Address는 클래스 이름으로 적합하다.
정리
좋은 이름을 선택하려면 설명 능력이 뛰어나야 하고 문화적인 배경이 같아야 한다. 좋은 이름을 선택하는 능력은 기술, 비즈니스, 관리 문제가 아니라 교육 문제다.
우리들 대다수는 자신이 짠 클래스 이름과 메서드 이름을 모두 암기하지 못한다.
이 장에서 소개한 규칙 몇 개를 적용해 코드 가독성이 높아지는지 살펴보자. 다른 사람이 짠 코드를 손본다면 리팩터링 도구를 사용해 문제 해결 목적으로 이름을 개선하자. 단기적인 효과는 물론 장기적인 이익도 보장된다.
