클린 코드 2장 의미 있는 이름

의도를 분명히 밝혀라

변수나 함수 그리고 클래스 이름은 다음과 같은 굵직한 질문에 모두 답해야 한다. 변수(혹은 함수나 클래스)의 존재 이유는? 수행 기능은? 사용 방법은? 따로 주석이 필요하다면 의도를 분명히 드러내지 못했다는 말이다.

int d; // 경과 시간(단위: 날짜)

// ==== 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;
}

위 코드는 복잡한 문장도 없고 길이도 적당하지만 코드가 하는 일을 짐작하기 어렵다. 문제는 코드의 단순성이 아니라 코드의 함축성이다. 다시 말해, 코드 맥락이 코드 자체에 명시적으로 드러나지 않는다. 위 코드는 암암리에 독자가 다음과 같은 정보를 안다고 가정한다.

1. theList에 무엇이 들었는가?
2. theList에서 0번째 값이 어째서 중요한가?
3. 값 4는 무슨 의미인가?
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(x);
		return flaggedCells;
}

단순성은 변하지 않았고 함수의 이름만 바꿔줬어도 훨씬 명확해졌다.

int 배열 대신 칸을 간단한 클래스로 만들고 isFlagged라는 명시적인 함수를 사용해 FLAGGED라는 상수를 감춰주면 더욱 개선된다.

public List<Cell> getFlaggedCells() {
	List<Cell> flaggedCells = new ArrayList<Cell>();
	for (Cell cell : gameBoard)
		if (cell.isFlagged())
			flaggedCells.add(cell);
		return flaggedCells;
}

좋은 이름이 주는 위력

 

그릇된 정보를 피하라

프로그래머에게 List는 특수한 의미, 계정을 담는 컨테이너가 실제 List가 아니라면 accountList라 쓰지 않는다. (실제 List라도 List를 쓰지 않는 게 바람직하다.) accountGroup, brunchOfAccounts, Accounts 라 명명한다.

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

한 모듈에서 XYZControllerForEfficientHandlingOfStrings 가 있고 조금 떨어진 모듈에서 XYZControllerForEfficientStorageOfStrings라는 이름을 쓴다면 겁나게 헷갈린다.

유사한 개념은 유사한 표기법을 사용한다. 이것도 정보다. 일관성이 떨어지는 표기법은 그릇된 정보다.

 

의미 있게 구분하라

• 연속적인 숫자 (a1, a2, ..., aN) - 아무런 정보도 제공하지 못한다.
• 불용어를 추가한 이름 - 역시 아무런 정보도 제공하지 못한다.
  • Product라는 클래스가 있다면 ProductInfo, ProductData는 개념을 구분하지 않은 채 이름만 달리 한 경우다. Info나 Data는 a, an, the와 마찬가지로 의미가 불분명한 불용어다.
  • getActiveAccount(); getActiveAccounts(); getActiveAccountInfo();
  • monyAmount - money customerInfo - customer accountData - account theMessage - message
  • 위 경우들은 서로 구분이 안 된다. 읽는 사람이 차이를 알도록 이름을 지어라

 

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

class DtaRcrd102 {
	private Date genymdhms;
	private Date modymdhms;
	private final String pszqint = "102";
	/* ... */
};

vs

class Customer {
	private Date generationTimestamp;
	private Date modificationTimestamp;
	private final String recordId = "102";
	/* ... */
};

 

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

문자 하나를 사용하는 이름과 상수는 쉽게 눈에 띄지 않는다.

MAX_CLASSES_PER_STUDENT는 찾기 쉽지만 7은 은근히 까다롭다.

e라는 문자도 변수 이름으로 적합하지 못하다. e는 영어에서 가장 많이 쓰이는 문자. 검색이 어렵다.

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

for (int j=0; j<34; j++) {
	s += (t[j]*4)/5;
}

vs

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 = (realTaskDays / WORK_DAYS_PER_WEEK);
	sum += realTaskWeeks;
}

위 코드에서 sum이 별로 유용하진 않으나 최소한 검색이 가능하다. 이름을 의미있게 지으면 함수가 길어진다. 하지만 WORK_DAYS_PER_WEEK를 찾기가 얼마나 쉬운지 생각해보라. 그냥 5를 사용한다면 5가 들어가는 이름을 모두 찾은 후 의미를 분석해 원하는 상수를 가려내야 한다.

 

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

독자가 코드를 읽으면서 변수 이름을 자신이 아는 이름으로 변환해야 한다면 그 변수 이름은 바람직하지 못하다. 이는 일반적으로 문제 영역이나 해법 영역에서 사용하지 않는 이름을 선택했기 때문에 생기는 문제다.

똑똑한 프로그래머와 전문가 프로그래머 사이에서 나타나는 차이점 하나만 들자면, 전문가 프로그래머는 명료함이 최고라는 사실을 이해한다.

 

클래스 이름

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

좋은 예
Customer, WikiPage, Account, AddressParser

나쁜 예
Manager, Processor, Data, Info

동사는 사용하지 않는다.

메서드 이름

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

좋은 예
postPayment, deletePage, save

접근자(Accessor), 변경자(Mutator), 조건자(Predicate)는 (javabean 표준에 따르면) get, set, is를 붙인다.

string name = employee.getName();
customer.setName("mike");
if (paycheck.isPosted())...

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

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

Complex fulcrumPoint = Complex.FromRealNumber(23.0);

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

Complex fulcrumPoint = new Complex(23.0);

 

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

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

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

마찬가지로, 동일 코드 기반에 controller, manager, driver를 섞어 쓰면 혼란스럽다. DeviceManager와 ProtocolController는 근본적으로 어떻게 다른가? 어째서 둘 다 Manager가 아닌가? 정말 둘 다 Driver가 아닌가?

이름이 다르다면 독자는 당연히 클래스도 다르고 타입도 다르리라 생각한다.

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

 

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

모든 이름을 문제 영역(도메인)에서 가져오는 정책은 현명하지 못하다.

코드를 읽을 사람도 프로그래머라는 사실을 명심한다. 프로그래머에게 익숙한 기술 개념은 아주 많다. 기술 개념에는 기술 이름이 가장 적합한 선택이다.

 

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

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

우수한 프로그래머와 설계자라면 해법 영역과 문제 영역을 구분할 줄 알아야 한다.

 

의미 있는 맥락을 추가하라

클래스, 함수, 이름 공간에 넣어 맥락을 부여한다. 모든 방법이 실패하면 마지막 수단으로 접두어를 붙인다.

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

변수를 훑어보면 주소라는 사실을 금방 알아챈다. 하지만 어느 메서드가 state라는 변수 하나만 사용한다면 변수 state가 주소의 일부라는 사실을 알아채기 어렵다.

addr라는 접두어를 추가해 addrFirstName, addrLastName, addrState라 쓰면 맥락이 좀 더 분명해진다. 변수가 좀 더 큰 구조에 속한다는 사실이 적어도 독자에게는 분명해진다.

물론 Address라는 클래스를 생성하면 더 좋다. 그러면 변수가 좀 더 큰 개념에 속한다는 사실이 컴파일러에게도 분명해진다.

맥락이 불분명한 변수. 함수 이름은 맥락 일부만 제공하며, 알고리즘이 나머지 맥락을 제공한다. 함수를 끝까지 읽어보고 나서야 number, verb, pluralModifire라는 변수를 이해할 수 있다.

불행히도 독자가 맥락을 유추해야만 한다. 그냥 메서드만 훑어서는 세 변수의 의미가 불분명하다.

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";
		pluralModifire = "";
	} else {
		number = Integer.toString(count);
		verb = "are";
		pluralModifier = "s";
	}
	String guessMessage = String.format(
		"There %s %s%s", verb, number, candidate, pluralModifier
	};
	print(guessMessage);
}

일단 함수가 좀 길다. 세 변수를 함수 전반에 사용한다. 함수를 작은 조각으로 쪼개고자 GuessStatisticsMessage라는 클래스를 만든 후 세 변수를 클래스에 넣었다. 그러면 세 변수는 맥락이 분명해진다. 즉 세 변수는 확실하게 GuessStatisticsMessage에 속한다. 이렇게 맥락을 개선하면 함수를 쪼개기가 쉬워지므로 알고리즘도 좀 더 명확해진다.

public class GuessStatisticsMessage {
	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, pluralModifre );
	}

	private void createPluralDependentMessageParts(int count) {
		if (count == 0) {
			thereAreNoLetters();
		} else if (count == 1) {
			thereIsOneLetter();
		} else {
			thereAreManyLetters(count);
		}
	}

	private void thereAreManyLetters(int count) {
		number = Integer.toString(count)
		verb = "are";
		pluralModifier = "s";
	}

	private void thereIsOneLetter() {
		number = "1";
		verb = "is";
		pluralModifier = "";
	}

	private void thereAreNoLetters() {
		number = "no";
		verb = "are";
		pluralModifier = "s";
	}
}

 

불필요한 맥락을 없애라

일반적으로는 짧은 이름이 긴 이름보다 좋다. 단, 의미가 분명한 경우에 한해서다. 이름에 불필요한 맥락을 추가하지 않도록 주의한다.

'고급 휘발유 충전소 Gas Station Deluxe'라는 애플리케이션을 짠다고 가정하다. 모든 클래스 이름을 GSD로 시작하겠다는 생각은 전혀 바람직하지 못하다.

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

 

---

 

나쁜 예를 읽으면서 내가 어제 오늘 짰던 코드들이 떠올라 마음이 아팠다.

네이밍은 항상 어렵다 🥲 

고민하고 고치고 고치다 보면 나아지겠지!!!