미니 블로그 : 메모하는 습관

otrodevym

2장, 의미 있는 이름
들어가면서
소프트웨어에서 이름은 어디서나 쓰인다. 여기저기에서 이름을 쓰므로 이름을 잘 지으면 여러모로 편하다. 이 장에서는 이름을 잘 짓는 간단한 규칙을 몇 가지 소개한다.
의도를 분명히 밝혀라
"의도가 분명하게 이름을 지으라"고 말하기는 쉽다.
여기서는 의도가 분명한 이름이 정말로 중요하다는 사실을 강조한다. 좋은 이름을 지으려면 시간이 걸리지만 좋은 이름으로 절약하는 시간이 훨씬 더 많다. 그러므로 이름을 주의 깊게 살펴 더 나은 이름이 떠오르면 개선하기 바란다. 그러면 (자신을 포함해) 코드를 읽는 사람이 더 행복해지리라.
변수나 함수 그리고 클래스 이름은 다음과 같은 굵직한 질문에 모두 답해야 한다.
변수(혹은 함수나 클래스)의 존재 이유는?
수행 기능은?
사용 방법은?
따로 주석이 필요하다면 의도를 분명히 드러내지 못했다는 말이다.
int d; // 경과 시간(단위: 날짜)
// 위에보다 아래가 더 낫다.
int elapsedTimeInDays;
int daysSinceCreation;
int daysSinceModification;
int fileAgeInDays;
다음 코드는 어떤가?
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<int[]> getFlaggedCells() {
	List<int[]> flaggedCells = new ArrayList<int[]>();
	for (int[] cell : gameBoard) 
		if (cell[STATUS_VALUE] == FLAGGED)
			flaggedCells.add(cell);
	return flaggedCells;
}
// 칸을 int 배열보다는 클래스로 만들어도 되겠다.
public List<Cell> getFlaggedCells() {
	List<Cell> flaggedCells = new ArrayList<Cell>();
	for (Cell cell : gameBoard) 
		if (cell.isFlagged())
			flaggedCells.add(cell);
	return flaggedCells;
}
위 코드의 문제는 함축성이다.
코드의 맥락이 코드 자체에 명시적으로 드러나지 않는다. 위 코드는 암암리에 독자가 다음과 같은 정보를 안다고 가정한다.
theList에 무엇이 들었는가?
theList에서 0번째 값이 어째서 중요한가?
값 4는 무슨 의미인가?
함수가 반환하는 리스트 list1을 어떻게 사용하는가?
지뢰찾기 게임을 만든다고 가정하면 theList가 게임판이라는 사실을 안다.
위 코드의 각 개념에 이름만 붙여도 코드가 상당히 나아진다.
그릇된 정보를 피하라
프로그래머는 코드에 그릇된 단서를 남겨서는 안 되고 그릇된 단서는 코드 의미를 흐린다.
나름대로 널리 쓰이는 의미가 있는 단어를 다른 의미로 사용해도 안 된다.
예를 들어 hp, aix, sco는 변수 이름으로 적합하지 않는데 유닉스 플랫폼이나 유닉스 변종을 가리키는 이름이기 때문이다.
직삼각형의 빗변을 구현할 때는 hp가 훌륭한 약어로 보일지라도 hp라는 변수는 독자에게 그릇된 정보를 제공한다.
여러 계정을 그룹으로 묶을 때, 실제 List가 아니라면, accountList라 명명하지 않는다.
프로그래머에게 List라는 단어는 특수한 의미이므로 계정을 담는 컨테이너가 실제 List가 아니라면 그릇된 정보를 제공하는 셈이다.(실제 컨테이너가 List인 경우라도 컨테이너 유형을 이름에 넣지 않는 편이 바람직하다.)
그러므로 accountGroup, bunchOfAccounts, 아니면 단순히 Accounts라 명명한다.
서로 흡사한 이름을 사용하지 않도록 주의한다.
유사한 개념은 유사한 표기법을 사용한다. 이것도 정보다. 일관성이 떨어지는 표기법은 그릇된 정보다.
십중팔구 개발자는 (객체에 달린 상세한 주석이나 클래스가 제공하는 메서드 목록을 살펴보지 않은채) 이름만 보고 객체를 선택한다.
글꼴 중 소문자 l과 대문자 O는 끔찍하다 글꼴을 바꿔서 사용하자.
의미 있게 구분하라
컴파일러나 인터프리터만 통과하려는 생각으로 코드를 구현하는 프로그래머는 스스로 문제를 일으 킨다.
동일한 범위 안에서 다른 개념에 같은 이름을 사용하지 못하기에 한 쪽 이름을 마음대로 바꾸고픈 유혹에 빠진다. 어떤 프로그래머는 철자를 살짝 바꿨다가 철자 오류를 고치는 순간 컴파일이 불가한 상황에 빠진다.(진짜 황당한 예는 class를 사용했다고 klass를 사용한다.)
이름이 달라야 한다면 의미도 달라져야 한다.
public static void copyChars(char a1[], char a2[]) {
	for (int i = 0; i < a1.length; i++) {
		a2[i] = a1[i];
	}
}
// 함수 인수를 source와 destination을 사용한다면 코드 읽기가 훨씬 더 쉬워진다.
불용어(noise word)를 추가한 이름 역시 아무런 정보도 제공하지 못한다.
Product라는 클래스가 있다고 가정하자.
다른 클래스를 ProductInfo 혹은 ProductData라 부른다면 개념을 구분하지 않은 채 이름만 달리한 경우다.
Info나 Data는 a, an, the와 마찬가지로 의미가 불분명한 불용어다.
a나 the와 같은 접두어를 사용하지 말라는 의미는 아니고 의미가 분명하다면 무방하다. 예를 들어 모든 지역 변수는 a를 사용하고 모든 함수 인수는 the를 사용해도 되겠다.(최근에는 특정 변수가 지역변수인지 함수 인수인지를 쉽게 구분할 수 있으므로 명시적으로 변수가 속한 영역을 구분할 필요가 없다.)
요지는 zork라는 변수가 있다는 이유만으로 theZork라 이름 지어서는 안 된다는 말이다.
불용어는 중복이다. 변수 이름에 variable이라는 단어는 단연코 금물이다. 표 이름에 table이라는 단어도 마찬가지다.
NameString이 Name보다 뭐가 나은가?
Name이 부동소수가 될 가능성이 있던가?
만약 가능성이 있다면 앞서 언급한 "그릇 된 정보를 피하라" 규칙을 위반한다.
코드를 읽다가 Customer라는 클래스와 CustomerObject라는 클래스를 발견했다면 차이를 알겠는가?
고객 급여 이력을 찾으려면 어느 클래스를 뒤져야 빠를까?
개발자를 보호하고자 이름을 바꿨으나 오류 형태는 정확히 다음과 같다.
getActiveAccount();
getActiveAccounts();
getActiveAccountInfo();
이 프로젝트에 참여한 프로그래머는 어느 함수를 호출할지 어떻게 알까?
명확한 관례가 없다면 변수 moneyAmount는 money와 구분이 안 된다.
customerInfo는 customer와, accountData는 account와, theMessage는 message와 구분이 안 된다.
읽는 사람이 차이를 알도록 이름을 지어라.
발음하기 쉬운 이름을 사용하라
사람들은 단어에 능숙하다. 우리 두뇌에 상당 부분은 단어라는 개념만 전적으로 처리한다. 그러므로 발음하기 쉬운 이름을 선택한다.
발음하기 어려운 이름은 토론하기도 어렵다 바보처럼 들리기 십상인데 "흠, 여기 비 씨 알 3 씨 앤 티 에스 지큐 int가 있군요." 발음하기 쉬운 이름은 중요하다.
프로그래밍은 사회 활동이기 때문이다.
class DtaRcrd102 {
	private Date genymdhms;
	private Date modymdhms;
	private final String pszqint = "102";
}
// 위에보다 아래가 명확하다.
class Customer {
	private Date gernerationTimestamp;
	private Date modificationTimestamp;
	private final String recordId = "102";
}
둘째 코드는 지적인 대화가 가능하다. "마이키, 이 레코드 좀 보세요. 'Generation Timestamp'값이 내일 날짜입니다! 어떻게 이렇죠?"
검색하기 쉬운 이름을 사용하라
문자 하나를 사용하는 이름과 상수는 텍스트 코드에서 쉽게 눈에 띄지 않는다는 문제점이 있다.
이런 관점에서 긴 이름이 짧은 이름보다좋다. 검색하기 쉬운 이름이 상수보다 좋다.
개인적으로는 간단한 메서드에서 로컬 변수만 한 문자를 사용한다. 이름 길이는 범위 크기에 비례해야 한다.
for (int j=0; j<34; j++) {
	s += (t[j]*4)/5;
}
// 위에와 아래의 코드를 비교하면 sum은 유용하지 않지만 WORK_DAYS_PER_WEEK는 5보다 찾기 쉽다.
int realDaysPerIdeaDay = 4;
const int WORK_DAYS_PER_WEEK = 5;
int sum = 5;
for (int j=0; j < NUMBER_OF_TASKS; j++) {
	int realTaskDays = taskEstimate[j] & realDaysPerIdealDay;
	int realTaskWeeks = (realTaskDays / WORK_DAYS_PER_WEEK);
	sum += realTaskWeeks;
}
인코딩을 피하라
굳이 부담을 더하지 않아도 이름에 인코딩할 정보는 아주 많다.
유형이나 범위 정보까지 인코딩에 넣으면 그만큼 이름을 해독하기 어려워진다.
대개 새로운 개발자가 익힐 코드 양은 상당히 많은데 여기에 인코딩 '언어'까지 익히라는 요구는 비합리적이다.
문제 해결에 집중하는 개발자에게 인코딩은 불필요한 정신적 부담이다.
해석해주어야 하는 '언어'를 의미하는듯하다.
헝가리식 표기법
이름 길이가 제한 된 언어를 사용하던 옛날에는 어쩔 수 없이 안타까워하면서도 이 규칙을 위반했다.
포트란은 첫 글자로 유형을 표현했다.
요즘 나오는 언어는 훨씬 많은 타입을 지원하고 컴파일러가 타입을 기억하고 강제한다. 게다가 클래스와 함수는 점차 작아지는 추세다.
즉, 변수를 선언한 위치와 사용하는 위치가 멀지 않다.
따라서 이제는 헝가리식 표기법이나 기타 인코딩 방식이 오히려 방해가 될 뿐이다.
PhoneNumber phoneString;
// 타입이 바뀌어도 이름은 바뀌지 않는다.
멤버 변수 접두어
이제는 멤버 변수에 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;
	}
}
접두어는 옛날에 작성한 구닥다리 코드라는 징표가 되버린다.
인터페이스 클래스와 구현 클래스
때로는 인코딩이 필요한 경우도 있는데 예를 들어 도형을 생성하는 ABSTRACT FACTORY를 구현한다고 가정했을 떄 이 팩토리는 인터페이스 클래스이고 구현은 구현 클래스에서 한다.
그렇다면 두 클래스 이름을 어떻게 지어야 좋을까?
IShapeFactory와 ShapeFactory? 개인적으로 인터페이스 이름은 접두어를 붙이지 않는 편이 좋다고 생각한다.
나로서는 내가 다루는 클래스가 인터페이스라는 사실을 남에게 알리고 싶지 않다. 클래스 사용자는 그냥 ShapeFactory라고만 생각하면 좋겠다.
그래서 인터페이스 클래스 이름과 구현 클래스 이름 중 하나를 인코딩해야 한다면 구현 클래스 이름을 택하겠다.
ShapeFactoryImp나 심지어 CShapeFactory가 IShapeFactory보다 좋다.
자신의 기억력을 자랑하지 마라
독자가 코드를 읽으면서 변수 이름을 자신이 아는 이름으로 변환해야 한다면 그 변수 이름은 바람직하지 못하다.
이는 일반적으로 문제 영역이나 해법 영역에서 사용하지 않는 이름을 선택했기 때문에 생기는 문제다.
문자 하나만 쓰는 변수는 문제가 있지만 루프에서 사용하는 i, j, k는 괜찮다(l은 알아보기 힘드니 쓰지말자) 단, 루프 범위가 아주 작고 다른 이름과 충돌하지 않을 때만 괜찮다.
그 외에는 대부분 적절하지 못하다. 독자가 실제 개념으로 변환해야 하니까. 최악은 이미 a와 b를 사용하므로 c를 선택한다는 논리다.
똑똑한 프로그래머와 전문가 프로그래머 사이에서 나타나는 차이점 하나만 들자면, 전문가 프로그래머는 명료함이 최고라는 사실을 이해한다.
클래스 이름
클래스 이름과 객체 이름은 명사나 명사구가 적합하다.
적합
Customer
WikiPage
Account
AddressParser
...
부적합
Manager
Processor
Data
info
동사는 피한다.
메서드 이름
메서드 이름은 동사나 동사구가 적합하다
적합
postPayment
deletePage
save
...
접근자, 변경자, 조건자는 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);
기발한 이름은 피하라
이름이 너무 기발하면 저자와 유머 감각이 비슷한 사람만, 그리고 농담을 기억하는 동안만, 이름을 기억한다.
의도를 분명하고 솔직하게 표현하라.
한 개념에 한 단어를 사용하라
추상적인 개념 하나에 단어 하나를 선택해 이를 고수한다.
예를 들어, 똑같은 메서드를 클래스마다 fetch, retrieve, get으로 제각각 부르면 혼란스럽다.
메서드 이름은 독자적이고 일관적이어여지 프로그래머가 올바른 메서드를 선택한다.
마찬가지로, 동일한 코드 기반에 controller, manager, driver를 섞어 쓰면 혼란스럽다.
DiviceManager와 ProtocolController는 근본적으로 어떻게 다른가?
어째서 둘 다 Controller가 아닌가?
어째서 둘 다 Mananger가 아닌가?
정말 둘 다 Driver가 아닌가?
이름이 다르면 독자는 당연히 클래스도 다르고 타입도 다르리라 생각한다.
일관성 있는 어휘는 코드를 사용할 프로그래머가 반갑게 여길 선물이다.
말장난을 하지 마라
한 단어를 두 가지 목적으로 사용하지 마라. 다른 개념에 같은 단어를 사용한다면 그것은 말장난에 불과하다.
"한 개념에 한 단어를 사용하라"는 규칙을 따랐더니, 예를 들어 여러 클래스에 add라는 메서드가 생겼다. 모든 add 메서드의 매개변수와 반환 값이 의미적으로 똑같다면 문제가 없다.
하지만 때로는 프로그래머가 같은 맥락이 아닌데도 '일관성'을 고려해 add라는 단어를 선택하는데 문제는 집합에 넣을 때와 합을 구할 때가 다르므로 insert와 append라는 이름이 적당하다.
새 메서드를 add라 부른다면 이는 말장난이다.
프로그래머는 코드를 최대한 이해하기 쉽게 짜야 한다. 집중적인 탐구가 필요한 코드가 아니라 대충 훑어봐도 이해할 코드 작성이 목표다.
해법 영역에서 가져온 이름을 사용하라
코드를 읽는 사람도 프로그래머라는 사실을 명심한다. 그러므로 전산 용어, 알고리즘 이름, 패턴 이름, 수학 용어 등을 사용해도 괜찮다.
모든 이름을 문제 영역에서 가져오는 정책은 현명하지 못하는데 같은 문제의 개념을 다른 이름으로 이해하던 동료들이 매번 고객에게 의미를 물어야 하기때문이다.
VISITOR 패턴에 친숙한 프로그래머는 AccountVisitor라는 이름을 금방 이해한다. JobQueue를 모르는 프로그래머가 있을까? 프로그래머에게 익숙한 기술 개념은 아주 많다.
기술 개념에는 기술 이름이 가장 적합한 선택이다.
문제 영역에서 가져온 이름을 사용하라
적절한 '프로그래머 용어'가 없다면 문제 영역에서 이름을 가져온다. 그러면 코드를 보수하는 프로그래머가 분야 전문가에게 의미를 물어 파악할 수 있다.
우수한 프로그래머와 설계자라면 해법 영역과 문제 영역을 구분할 줄 알아야 한다.
문제 영역 개념과 관련이 깊은 코드라면 문제 영역에서 이름을 가져와야 한다.
의미 있는 맥락을 추가하라
스스로 의미가 분명한 이름이 없지 않다. 하지만 대다수 이름은 그렇지 못하기에 클래스, 함수, 이름 공간에 넣어 맥악을 부여한다. 모든 방법이 실패하면 마지막 수단으로 접두어를 붙인다.
예를 들어, firstName, lastName, street, houseNumber, city, state, zipcode라는 변수를 보면 주소라는걸 알 수 있지만 state 하나만 있으면 주소 일부라는 사실을 금방 알 수 있을까?
addr라는 접두어를 추가해 addrFirstName, addrLastName, addrState라 쓰면 맥락이 좀 더 분명해진다. 변수가 좀 더 큰 구조에 속한다는 사실도 적어도 독자에게는 분명해진다. 물론 Address라는 클래스를 생성하면 더 좋다. 그러면 변수가 좀 더 큰 개념에 속한다는 사실이 컴파일러에게도 분명해진다.
// 맥락이 불분명한 변수
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, pluralModifier
	);
	print(guessMessage);
}
// 맥락이 분명한 변수
// 함수가 좀 길고 세 변수가 전반에 사용되며 쪼갤 필요가 있다.
public class HuessStatisticMessage {
	private String number;
	private String verb;
	private String pluralModifier;
	public String make(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 thereAreManyLetters(int count) {..}
	private void thereIsOneLetter() {..}
	private void thereAreNoLetters() {..}
}
불필요한 맥락을 없애라
'고급 휘발유 충전소(Gas Station Deluxe)'라는 애플리케이션을 만든다고 가정했을 때 모든 클래스 이름을 GSD로 시작하겠다는 생각은 전혀 바람직하지 못하다.
솔직히 전봇대로 이 쑤시는 격이다.
일반적으로는 짧은 이름이 긴 이름보다 좋다. 단, 의미가 분명한 경우에 한해서다.
이름에 불필요한 맥락을 추가하지 않도록 주의한다.
accountAddress와 customerAddress는 Address 클래스 인스턴스로는 좋은 이름이나 클래스 이름으로는 적합하지 못하다. Address는 클래스 이름으로 적합하다.
마치면서
좋은 이름을 선택하려면 설명 능력이 뛰어나야 하고 문화적인 배경이 같아야 하는데 제일 어렵다. 좋은 이름을 선택하는 능력은 기술, 비즈니스, 관리 문제가 아니라 교육 문제다. 우리 분야 사람들이 이름 짓는 방법을 제대로 익히지 못하는 이유가 바로 여기에 있다.
사람들이 이름을 바꾸지 않으려는 이유 하나는 다른 개발자가 반대할까 두려워서다. 우리들 생가은 다르다. 오히려 (좋은 이름으로 바꿔주면) 반갑고 고맙다.
암기는 요즘 나오는 도구에게 맡기고, 우리는 문장이나 문단처럼 읽히는 코드 아니면(정보를 표시하는 최선의 방법이 항상 문장만은 아니므로) 적어도 표나 자료 구조처럼 읽히는 코드를 짜는 데만 집중해야 마땅하다.
여느 코드 개선 노력과 마찬가지로 이름 역시 나름대로 바꿨다가 누군가 질책할지도 모른다. 그렇다고 코드를 개선하려는 노력을 중단해서는 안 된다.

클린 코드 - 2장

댓글