2022-06-08 @이영훈
들어가면서
이 장에서는 이름을 잘 짓는 간단한 규칙을 몇 가지 소개한다.
의도를 분명히 밝혀라
의도가 분명하게 이름을 지어라. 좋은 이름을 지으려면 시간이 걸리지만 좋은 이름으로 절약하는 시간이 훨씬 더 많다.
변수나 함수, 클래스 이름은 다음과 같은 질문에 모두 답해야한다.
•
변수(또는 함수, 클래스)의 존재 이유는?
•
수행 기능은?
•
사용 방법은?
•
따로 주식이 필요하다면 의도를 분명히 드러내지 못했다는 말이다.
// ❌ 나쁜 예
int d; // 경과 시간(단위: 날짜)
// ⭕️ 좋은 예
int elaspedTimeInDays;
int daysSinceCreation;
int daysSinceModification;
int fileAgeInDays;
Java
복사
그릇된 정보를 피하라
프로그래머는 코드에 그릇된 단서를 남겨서는 안 된다. 그릇된 단서는 코드 의미를 흐린다.
여러 계정을 그룹으로 묶을 때, 실제 List가 아니라면 accountList라 명명하지 않는다. 프로그래머에게 List라는 단어는 특수한 의미다.
accountGroup, accounts가 더 좋은 이름이다.
서로 흡사한 이름을 사용하지 않도록 주의한다. SomeControllerFroHandlingOfStrings 이름을 사용하고, 조금 떨어진 모듈에서 SomeControllerForStorageOfString라는 이름을 사용하면 차이를 모른다.
유사한 개념은 유사한 표기법을 사용한다. 이것도 정보다. 일관성이 떨어지는 표기법은 그릇된 정보다. IDE의 자동완성 기능에서 구분 가능할만큼 분명하게 표기해야한다.
의미 있게 구분하라
연속된 숫자를 덧붙이거나 Noise Word (불용어. ex) a, an, the, info, data 등)를 추가하는 방식은 적절하지 못하다.
연속적인 숫자를 덧붙인 이름(a1, a2, ,,, aN)은 의도적인 이름과 정반대다. 아무런 정보를 제공하지 못한다. 저자의 의도가 전혀 드러나지 않는다.
// ❌ 나쁜 예
public static void copyChars(char a1[], char a2[]) {
for (int i = 0; i < a1.length; i++) {
a2[i] = a1[i];
}
}
// ⭕️ 좋은 예
public static void copyChars(char source[], char destination[]) {
for (int i = 0; i < a1.length; i++) {
a2[i] = a1[i];
}
}
Java
복사
불용어를 추가한 이름 역시 아무런 정보도 제공하지 못한다. Product와 ProductInfo, ProductData라 부르는 경우는 개념을 구분하지 않은 채 이름만 달리한 경우다. NameString이 Name보다 뭐가 더 나은가?
발음하기 쉬운 이름을 사용하라
우리 두뇌에서 상당 부분은 단어라는 개념만 전적으로 처리한다. 그리고 정의상으로 단어는 발음이 가능하다.
발음하기 어려운 이름은 토론하기도 어렵다.
// ❌ 나쁜 예
LocalDateTime genymdhms; // generate date, year, month, day, hour, minute, second
// ⭕️ 좋은 예
LocalDateTime generationTimestamp;
LocalDateTime createTimestamp;
LocalDateTime createdAt;
Java
복사
검색하기 쉬운 이름을 사용하라
문자 하나를 사용하는 이름과 상수는 텍스트 코드에서 쉽게 눈에 띄지 않는다는 문제점이 있다.
MAX_CLASSES_PER_STUDENT는 찾기 쉽지만 7은 찾기 어렵다
WORK_DAYS_PER_WEEK는 찾기 쉽지만 5는 찾기 어렵다
긴 이름이 짧은 이름보다 좋다. 검색하기 쉬운 이름이 상수보다 좋다.
이름을 의미있게 지으면 함수가 길어진다. 하지만 WORK_DAYS_PER_WEEK를 찾기가 얼마나 쉬운지 생각해보라. 그냥 5를 사용한다면 5가 들어가는 이름을 모두 찾은 후 의미를 분석해 원하는 상수를 가려내야 하리라.
인코딩을 피하라
굳이 부담을 더하지 않아도 이름에 인코딩할 정보는 아주 많다. 유형이나 범위 정보까지 인코딩에 넣으면 그만큼 이름을 해독하기가 어려워진다.
1.
헝가리식 표현법
헝가리식 표현법: 변수 및 함수의 인자 이름 앞에 데이터 타입을 명시하는 코딩 규칙이다.
옛날에는 IDE가 부실해서, 옛날에는 컴파일러가 타입을 점검하지 않아서 사용했다고 한다.
// ❌ 나쁜 예
int nAge;
String strName;
Java
복사
2.
멤버 변수 접두어
멤버 변수에 m_이라는 접두어를 붙일 필요도 없다. 클래스와 함수는 접두가 필요없을 정도로 작아야 마땅하다. 또한 멤버 변수를 다른 색상으로 표시하거나 눈에 띄게 보여주는 IDE를 사용해야 마땅하다.
// ❌ 나쁜 예
public class Part {
private String m_description;
void setName(String name) {
m_description = name;
}
}
// ⭕️ 좋은 예
public class Part {
String description;
void setDescription(String description) {
this.description = description;
}
}
Java
복사
3.
인터페이스 클래스와 구현 클래스
때로는 인코딩이 필요한 경우도 있다.
예를 들어 도형을 생성하는 ABSTRACT_FACTORY를 구현한다고 가정하자. 이 팩토리는 인터페이스 클래스(interface class)다. 구현은 구현 클래스(concrete class)에서 한다.
개인적으로 인터페이스 이름은 접두어를 붙이지 않는 편이 좋다고 생각한다. 옛날 코드에서 많이 사용하는 접두어 I는 (잘해봤자) 주의를 흐트리고 (나쁘게는) 과도한 정보를 제공한다. (Typescript interface naming 내용)
그래서 인터페이스 클래스 이름과 구현 클래스 이름 중 하나를 인코딩해야 한다면 구현 클래스 이름을 택하겠다.
// ⭕️ 좋은 예
// 인터페이스
interface ShapeFactory {
...
}
class ShapeFactoryImpl implements ShapeFactory {
...
}
// 또는
class CShapeFactory implements ShapeFactory {
...
}
Java
복사
자신의 기억력을 자랑하지 마라
독자가 코드를 읽으면서 변수 이름을 자신이 아는 이름을 변환해야 한다면 그 변수 이름은 바람직하지 못하다. 일반적으로 문제 영역이나 해법 영역에서 사용하지 않는 이름을 선택했기 때문에 생기는 문제다.
문자 하나만 사용하는 변수 이름. 루프에서 반복 횟수를 세는 변수 i,j,k는 괜찮다 (l은 절대 안된다). 다른 경우에는 대부분 적절하지 못하다.
명료함이 최고다
전문가 프로그래머는 자신의 능력을 좋은 방향으로 사용해 남들이 이해하는 코드를 내놓는다.
클래스 이름
클래스 이름과 객체 이름은 명사나 명사구가 적합하다
Manager, Processor, Data, Info 같은 단어는 피하고, 동사는 사용하지 않는다.
// ⭕️ 좋은 예
class Customer { }
class WikiPage { }
class Account { }
class AddressParser { }
Java
복사
메서드 이름
메서드 이름은 동사나 동사구가 적합하다.
접근자, 변경자, 조건자는 javabean 표준에 따라 앞에 get, set, is를 붙인다
// ⭕️ 좋은 예
String name = employee.getName();
customer.setName("mike");
if (paycheck.isPosted());
Java
복사
생성자를 중복정의 할 때는 정적 팩토리 메서드를 사용한다. 메서드는 인수를 설명하는 이름을 사용한다.
// ❌ 나쁜 예
Complex fulcrumPoint = new Complex(23.0);
// ⭕️ 좋은 예
Complex fulcrumPoint = Complex.FromRealNumber(23.0);
Java
복사
기발한 이름은 피하라
// ⭕️ 좋은 예
kill()
// ❌ 나쁜 예
whack() // 문화권이 달라서 무슨 말인지 모르겠다. 무슨 콘텐츠에서 나왔을지...?
Java
복사
한 개념에 한 단어를 사용하라
추상적인 개념 하나에 단어 하나를 선택해 이를 고수한다.
예를 들어, 똑같은 메서드를 클래스마다 fetch, retreive, get으로 제각각 부르면 혼란스럽다.
마찬가지로 동일 코드 기반에 controller, manager, driver를 섞어서 쓰면 혼란스럽다.
말장난을 하지 마라
한 단어를 두 가지 목적으로 사용하지 마라. 다른 개념에 같은 단어를 사용한다면 그것은 말장난에 불과하다.
“한 개념에 한 단어를 사용하라"라는 규칙을 따랐더니, 예를 들어, 여러 클래스에 add라는 메서드가 생겼다. 모든 메서드의 매개변수와 반환값이 의미적으로 똑같다면 문제가 없다.
하지만 지금까지 구현한 add 메서드는 모두가 기존 값 두 개를 더하거나 이어서 새로운 값을 만든다고 가정하자. 새로 작성하는 add 메서드는 집합에 값 하나를 추가한다. 이는 insert나 append라는 이름이 적당하다.
의미를 해독할 책임이 독자에게 있는 논문 모델이 아니라 의도를 밝힐 책임이 저자에게 있는 잡지 모델이 바람직하다.
해법 영역에서 가져온 이름을 사용하라
코드를 읽는 사람도 프로그래머라는 사실을 명심한다. 그러므로 전산 용어, 알고리즘 이름, 패턴 이름, 수학 용어 등을 사용해도 괜찮다. 모든 이름을 문제 영역에서 가져오는 정책은 현명하지 못하다.
문제 영역에서 가져온 이름을 사용하라
적절한 ‘프로그래머 용어'가 없다면 문제 영역에서 이름을 가져온다. 그러면 코드를 보수하는 프로그래머가 분야 전문가에게 의미를 물어 파악할 수 있다.
의미 있는 맥락을 추가하라
클래스, 함수, 이름 공간에 넣어 맥락을 부여한다. 모든 방법이 실패하면 마지막 수단으로 접두어를 붙인다.
firstName, lastName, street, houseNumber, city, state, zipcode 변수를 훑어보면 주소라는 사실을 금방 알아챈다. 하지만 state라는 변수 하나만 사용한다면? 어렵다
addr라는 접두어를 추가해 addrFirstName, addrLastName, addrState라 쓰면 맥락이 좀더 분명해진다. 물론 Address라는 클래스를 생성하면 더 좋다.
불필요한 맥락을 없애라
고급 휘발유 충전소 (Gas Station Deluxe)라는 애플리케이션을 짠다고 가정하자. 모든 클래스 이름을 GSD로 시작하겠다라는 생각은 전혀 바람직하지 못하다.
일반적으로 짧은 이름이 긴 이름보다 좋다. 단 의미가 분명한 경우에 한해서다. 이름에 불필요한 맥락을 추가하지 않도록 주의한다.
마치면서
좋은 이름을 선택하려면 설명 능력이 뛰어나야 하고 문화적인 배경이 같아야 한다. 이것이 제일 어렵다. 좋은 이름을 선택하는 능력은 기술, 비즈니스, 관리 문제가 아니라 교육 문제다.
사람들이 이름을 바꾸지 않으려는 이유 하나는 다른 개발자가 반대할까 두려워서다. 우리들 생각은 다르다. 오히려 (좋은 이름으로 바꿔주면) 반갑고 고맙다.
우리들 대다수는 자신이 짠 클래스 이름과 메서드 이름을 모두 암기하지 못한다. 암기는 요즘 나오는 도구에게 맡기고, 우리는 문장이나 문단처럼 읽히는 코드 아니면 적어도 표나 자료 구조처럼 읽히는 코드를 짜는 데만 집중해야 마땅하다.