Clean Code, Chapter 2: Meaningful Names by Tim Ottinger #747
Description
2. 의미 있는 이름, 팀 오팅어(Tim Ottinger)
들어가면서
소프트웨어에서 이름은 어디나 쓰인다.
이름을 잘 지으면 여러 모로 편하다.
이름을 잘 짓는 간단한 규칙을 알아본다.
의도를 분명히 밝혀라
의도가 분명한 이름이 정말로 중요하다.
좋은 이름을 지으려면 시간이 걸리지만 좋은 이름으로 절약하는 시간이 훨씬 더 많다.
더 나은 이름이 떠오르면 개선해야 한다.
따로 주석이 필요하다면 의도를 분명히 드러내지 못했다는 뜻이다.
int d; // 경과 시간(단위: 날짜)이름 d는 아무 의미도 드러나지 않는다.
측정하려는 값과 단위를 표현하는 이름이 필요하다.
int elapsedTimeInDays;의도가 드러나는 이름을 사용하면 코드 이해와 변경이 쉬워진다.
아래 코드는 무엇을 하는 코드일까?
public List<int[]> getThem() {
List<int[]> list1 = new ArrayList<int[]>();
for (int[] x : theList)
if (x[0] == 4)
list1.add(x);
return list1;
}문제는 코드의 단순성이 아니라 코드의 함축성이다.
코드 맥락이 코드 자체에 명시적으로 드러나지 않는다.
이 코드는 암묵적으로 다음과 같은 정보를 안다고 가정하는 것이다.
- theList에 무엇이 들었는지
- theList에서 0번째 값의 의미
- 4를 체크하는 의미
- 반환하는 list1은 어떻게 사용하는가?
이 코드는 지뢰찾기 게임을 만드는 것으로 theList는 게임판이므로 이름을 gameBoard로 바꾼다.
게임판에서 각 칸은 단순 배열로 표현한다. 배열에 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 배열을 사용하는 대신 클래스로 대체하는게 더 좋다.
그리고 isFlagged라는 명시적인 함수를 통해 체크한다.
다시 개선한 코드는 다음과 같다.
public List<Cell> getFlaggedCells() {
List<Cell> flaggedCells = new ArrayList<Cell>();
for (Cell cell : gameBoard)
if (cell.isFlagged())
flaggedCells.add(cell);
return flaggedCells;
}이름만 고쳐도 함수가 하는 일을 이해하기 쉬워졌다.
이것이 좋은 이름이 주는 위력이다.
그릇된 정보를 피하라
프로그래머는 코드에 그릇된 단서를 남겨서는 안 된다.
그릇된 단서는 코드 의미를 흐린다.
널리 쓰이는 의미가 있는 단어를 다른 의미로 사용해도 안 된다. 예) hp, aix, sco
List라는 단어도 특수한 의미다.
계정을 담는 컨테이너가 실제 List가 아니라면 프로그래머에게 그릇된 정보를 제공하는 것이다.
accountList 대신 accountGroup, bunchOfAccounts, Accounts 등으로 쓴다.
유사한 개념은 유사한 표기법을 사용한다. 이것도 정보다.
일관성이 떨어지는 표기법은 그릇된 정보다.
IDE에서 코드 자동 완성 기능을 통해 이름 후보를 선택할 수 있는 유용한 기능이 있다.
이름으로 그릇된 정보를 제공하는 예는 소문자 L이나 대문자 O 변수이다.
이건 숫자1, 숫자0 처럼 보이기 때문에 문제가 된다.
이런 경우 글꼴을 바꿔서 해결하던가 이름을 바꿔야 한다.
의미 있게 구분하라
컴파일러나 인터프리터만 통과하려는 생각으로 코드를 구현하는 프로그래머는 스스로 문제를 일으킨다.
컴파일러를 통과해도 연속된 숫자를 덧붙이거나 불용어noise word를 추가하는 방식은 적절하지 못하다.
이름이 달라야 한다면 의미도 달라져야 한다.
a1, a2와 같은 이름은 아무런 정보를 제공하지 못하는 이름이며 저자 의도가 전혀 드러나지 않는다.
public static void copyChars(char a1[], char a2[]) {
for (int i=0; i < a1.length; i++) {
a2[i] = a1[i];
}
}이 경우 함수 인수 이름으로 source와 destination을 사용하면 코드 읽기가 훨씬 쉬워진다.
불용어를 추가한 이름도 아무런 정보를 제공하지 못한다.
Proudct 클래스에 다른 클래스를 ProductINfo, ProductData라 부르면 이름만 다르게 하는 경우다.
Info나 Data는 의미가 불분명한 불용어이다.
불용어는 중복이다.
변수 이름에 variable이라는 단어는 금물이다.
표 이름에 table이라는 단어도 마찬가지다.
NameString은 Name보다 뭐가 나은가?
Customer와 CustomerObject가 있다면 어떤 차이가 있는가?
읽는 사람이 차이를 알도록 이름을 지어야 한다.
발음하기 쉬운 이름을 사용하라
발음하기 어려운 이름은 토론하기 어렵고 바보처럼 들리기 쉽다.
"비씨알3씨엔티에피에스지큐 int" 가 예이다.
발음하기 쉬운 이름은 중요하다. 프로그래밍은 사회 활동이기 때문이다.
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, 문자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 = (realdays / WORK_DAYS_PER_WEEK);
sum += realTaskWeeks;
}sum이 별로 유용하진 않지만 최소한 검색이 가능하다.
의미 있는 이름을 지으면 함수는 길어지지만 WORK_DAYS_PER_WEEK를 찾기가 매우 쉬워진다.
인코딩을 피하라
문제 해결에 집중하는 개발자에게 인코딩은 불필요한 정신적 부담이다.
헝가리식 표기법
윈도 C API는 헝가리식 표기법을 중요하게 여겼다.
모든 변수는 정수 핸들, long 포인터, void 포인터, 여러 '문자열' 중 하나였다.
컴파일러가 타입을 점검하지 않았으므로 프로그래머에게 타입을 기억할 단서가 필요했다.
요즘 프로그래밍 언어는 많은 타입을 지원하고 컴파일러가 타입을 기억하고 강제한다.
이제 헝가리식 표기법이나 기타 인코딩 방식이 오히려 방해가 된다.
멤버 변수 접두어
멤버 변수에 m_ 이라는 접두어도 필요 없다.
IDE는 멤버 변수를 다른 색상으로 표시하거나 눈에 띄게 보여주는 IDE를 사용한다.
지금은 접두어나 접미어를 무시하고 이름을 해독하는 방식을 빨리 익힌다.
접두어는 옛날에 작성한 구닥다리 코드라는 징표가 되어버린다.
인터페이스 클래스와 구현 클래스
인터페이스 이름은 접두어를 붙이지 않는 편이 좋다.
옛날 코드에서 사용하는 접두어 I는 주의를 흐트리고 과도한 정보를 제공한다.
자신의 기억력을 자랑하지 마라
코드를 읽으면서 변수 이름을 자신이 아는 이름으로 변환해야 한다면 그 변수 이름은 바람직하지 못하다.
일반적으로 문제 영역이나 해법 영역에서 사용하지 않는 이름을 선택했기 때문에 생기는 문제다.
루프문에서 쓰는 i, j, k를 제외하고 문자 하나만 사용하는 변수 이름은 문제가 있다.
최악은 a와 b가 있으니까 c를 선택한다는 논리다.
프로그래머들은 똑똑하므로 때때로 자신의 정신적 능력을 과시하고 싶어한다.
r이라는 변수가 호스트와 프로토콜을 제외한 소문자 URL이라는 사실을 언제나 기억한다면 똑똑한 사람이다.
이제 전문가와 차이점 하나만 얘기해 보면
전문가는 명료함이 최고라는 사실을 이해하고
자신의 능력을 좋은 방향으로 사용해 남들이 이해하는 코드를 작성한다.
클래스 이름
클래스 이름과 객체 이름은 명사나 명사구가 적합하다.
Customer, WikiPage, Account, AddresParser 등이 좋은 예다.
Manager, Processor, Data, Info 등과 같은 단어는 피하고 동사는 사용하지 않는다.
메서드 이름
메서드 이름은 동사나 동사구가 적합하다.
postPayment, deletePage, save 등이 좋은 예다.
접근자Accessor, 변경자Mutator, 조건자Predicate는 javabean 표준에 따라 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으로 선언한다.
기발한 이름은 피하라
기발한 이름은 저자와 유머 감각이 비슷한 사람과 농담을 기억하는 기간만 그 이름을 기억하게 된다.
재미난 이름보다 명료한 이름을 선택한다.
특정 문화에서만 사용하는 농담은 피하고 의도를 분명하고 솔직하게 표현한다.
한 개념에 한 단어를 사용하라
추상적인 개념 하나에 단어 하나를 선택해 규칙으로 만든다.
똑같은 메서드를 클래스마다 fetch, retrieve, get으로 각각 부르면 혼란스럽다.
현실에서는 이름을 기억하기 위해 라이브러리 회사, 그룹, 개인을 기억해야 하는 경우가 있다.
최신 IDE를 쓰면 문맥에 맞는 단서를 제공하는데 객체를 사용하면 메서드 목록을 보여주는 식이다.
따라서 메서드 이름은 독자적이고 일관적이어야 한다.
그래야 올바른 메서드를 선택할 수 있다.
이름이 다르면 독자는 당연히 클래스도 다르고 타입도 다르다고 생각한다.
일관성 있는 어휘는 코드를 사용할 프로그래머가 반갑에 여길 선물이다.
말장난을 하지 마라
한 단어를 두 가지 목적으로 사용하지 않는다.
다른 개념에 같은 단어를 사용하면 그것은 말장난에 불과하다.
예로 add 메서드는 모두 기존 값 두 개를 더하거나 이어서 새로운 값을 만드는 개념으로 썼는데
새로 작성하는 메서드는 집합에 값 하나를 추가한다면 add 메서드라고 하면 안된다.
기존 add 메서드와 맥락이 다르다면 insert나 append라는 이름이 적당하다.
프로그래머는 코드를 최대한 이해하기 쉽게 짜야 한다.
집중적인 탐구가 필요한 코드가 아니라 대충 훑어봐도 이해할 코드 작성이 목표다.
해법 영역에서 가져온 이름을 사용하라
코드를 읽을 사람도 프로그래머라는 사실을 명심한다.
그러므로 전산 용어, 알고리즘 이름, 패턴 이름, 수학 용어 등을 사용해 괜찮다.
이름을 문제 영역domain에서 가져오는 건 현명하지 못하다.
같은 개념을 다른 이름으로 이해하면 매번 고객에게 의미를 물어야 하기 때문이다.
Visitor 패턴이나 JobQueue를 모르는 프로그래머는 없을 것이다.
프로그래머에게 익숙한 기술 개념은 많다.
기술 개념에는 기술 이름이 가장 적합한 선택이다.
문제 영역에서 가져온 이름을 사용하라
적절한 프로그래머 용어가 없다면 문제 영역에서 이름을 가져온다.
그러면 코드를 유지보수하는 프로그래머는 전문가에게 의미를 물어 파악할 수 있다.
우수한 프로그래머와 설계자는 해법 영역과 문제 영역을 구분해야 한다.
문제 영역 개념과 관련이 깊은 코드는 문제 영역에서 이름을 가져와야 한다.
의미 있는 맥락을 추가하라
대부분 의미가 분명한 이름이 있지만, 대다수 이름은 그렇지 못하다.
그래서 클래스, 함수, 이름 공간에 넣어 맥락을 부여한다.
이런 방법을 쓸 수 없을 때 마지막 수단으로 접두어를 붙인다.
변수 이름이 firstName, lastName, street, houseNumber, city, state, zipcode 라면 주소와 관련된 사실을 알 수 있다.
하지만 state 변수 하나만 놓고 사용한다면 주소 일부라는 사실을 금방 알아채기는 어렵다.
접두어 addr를 붙여 addrState라 쓰면 맥락이 분명해지며
Address라는 클래스를 생성하면 더 좋다.
불필요한 맥락을 없애라
고급 휘발유 충전소Gas Station Deluxe라는 애플리케이션을 작성한다고 했을 때
모든 클래스 이름을 GSD를 붙이겠다는 생각은 바람직하지 않다.
GSD로 시작하는 수십개의 클래스를 작성했을 때 IDE에서 G를 입력해 자동 완성으로 보여주는 클래스 이름 목록은 그렇게 유용하지 않다.
GSD 회계 모듈에 MailingAddress 클래스를 추가하면서 GSDACcountAddress로 이름을 바꿨는데
나중에 다른 고객 관리 프로그램에서 고객 주소가 필요하다면 GSDACcountAddress라는 클래스 이름은 부적절하므로 사용하지 않을 것이다.
일반적으로 의미가 분명하다는 조건 하에 짧은 이름이 긴 이름 보다 좋다.
accountAddress, customerAddress는 Address 클래스 인스턴스로 좋은 이름이지 클래스 이름으로 좋은 이름은 아니다.
마치면서
좋은 이름을 선택하려면 설명 능력이 뛰어나야 하고 문화적인 배경이 같아야 한다. 이게 제일 어렵다.
좋은 이름을 선택하는 능력은 기술, 비즈니스, 관리 문제가 아니라 교육 문제다.
다른 개발자가 반대할까 두려워 이름을 바꾸지 않으려고 하는데
오히려 좋은 이름으로 바꿔주는게 좋다.
모두 자신이 작성한 클래스 이름과 메서드 이름을 모두 외우지 못한다.
그래서 도구를 사용하는 것이고
문장이나 문단처럼 읽히는 코드 혹은 표나 자료 구조처럼 읽히는 코드를 짜는데 집중해야 한다.
코드를 개선하려는 노력을 중단해서는 안 된다.