의도를 분명히 밝혀라

좋은 이름을 지으려면 시간이 걸리지만 좋은 이름으로 절약하는 시간이 훨씬 더 많다.

좋은 이름을 지으면 자신을 포함해 코드를 읽는 사람이 조금 더 행복해질 수 있다.

변수나 함수 그리고 클래스 이름은 다음과 같은 굵직한 질문에 모두 답해야한다. (따로 주석이 필요하면 의도를 들어내지 못했다는 것)

변수/함수/클래스의 존재의 이유는?
수행 기능은?
사용 방법은?

그릇된 정보를 피하라

코드에 그릇된 단서를 남겨서는 안 된다.

나름대로 널리 쓰이는 의미가 있는 단어를 다른 의미로 사용해서 안된다.

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

유사한 개념은 유사한 표기법을 사용한다.

이름으로 그릇된 정보를 제공하는 끔찍한 예가 소문자 L이나 대문자 O 변수다. (아래 코드)

int a = l;
if ( O == 1 ) {
	a = O1;
} else {
	l = 01;
}

의미 있게 구분하라

copyChars 메소드의 파라미터 변수명으로 a1, a2 같이 하지 말고.. source, destination 같은 것을 사용하면 더 알기 쉽다.

Product 라는 클래스가 있을 때 다른 클래스를 ProductInfo /. ProductData 로 하지 말자. 어떤것인지 알기 어렵다.

또 a 나 the 등의 무의미한 접두사를 붙이지 말자 (zork 라는 변수가 있다는 이유로 theZork 라는 새로운 변수를 쓰지 말자)

변수명에 variable 이라는 단어는 결단코 금물이다. 표 이름에 table 이라는 단어도 마찬가지다. (NameString 과 Name보다 뭐가 더 나은가?)

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

발음 하기 어려운 이름은 토론하기도 어렵다.

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

문자 하나를 사용하는 이름과 상수는 텍스트 코드에서 쉽게 눈에 띄지 않는다.

MAX_CLASSES_PER_STUDENT 는 grep 으로 찾기 쉽지만, 숫자 7은 은근히 까다롭다.

인코딩을 피하라

인코딩한 이름은 거의가 발음하기 어려우며 오타가 생기기도 쉽다.

헝가리식 표기법

이름길이가 제한된 언어를 사용하던 옛날에 어쩔 수 없이 썼다. 첫 글자에 유형을 표기해줬는데 요즘 언어에서는 큰 의미가 없다. (ex: String sName, String phoneString) → 이렇게 했을 때 type을 바꾸게 되어도 변수명은 그래도 있게 된다.

멤버 변수 접두어

IDE나 컴파일러가 알아서 잘 해주기 때문에.. 할필요가 없다.

인터페이스 클래스와 구현 클래스 - 인터페이스 클래스 이름과 구현 클래스 이름 중 하나를 인코딩해야 한다면 구현 클래스 이름을 택할 것. SharpeFactoryImp 나 CShapeFactory 가 IShapeFactory 보다 좋다

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

문자 하나만 사용하는 변수 이름은 문제가 있음. (루프에서 반복 횟수를 세는 변수 i,j,k 는 괜찮다.. l은 절대 안된다.) 혹은 루프 범위가 아주 작고 다른 이름과 충돌하지 않을 때는 괜찮다. 그 외에는 적절하지 않다.

클래스 이름

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

Customer, WikiPage, Account, AddressParser 등등..

Manager, Processor, Data, Info 등과 같은단어는 피하고 동사는 사용하지 않는다.

메서드 이름

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

postPayment, deletePage, save 등등..

자바의경우 접근자(accessor), 변경자(mutator), 조건자(predicate)는 get, set, is 를 앞에 붙인다. → 언어에 따라 다르다.

기발한 이름을 피하라

이름이 너무 기발하면 저자와 유머 감각이 비슷한 사람만, 그리고 농담을 기억하는 동안만 이름을 기억한다.

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

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

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

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

말장난을 하지 마라

한 단어를 두 가지 목적으로 사용하지 마라.

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

코드를 읽은 사람도 프로그래머를 사실을 명심한다. 그러므로 전산 용어, 알고리즘 이름, 패턴 이름, 수학 용어 등을 사용해도 괜찮다.

VISITOR 패턴에 친숙한 프로그래머는 AccountVisitor 라는 이름을 금방 이해하고 JobQueue 를 모르는 프로그래머는 없다.

기술 개념에는 기술 이름이 가장 적합한 선택이다.

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

적절한 프로그래머 용어가 없으면 문제 영역에서 이름을 가져온다.

의미 있는 맥락을 추가하라

스스로 의미가 분명한 이름이 없지는 않지만 대다수 이름은 그렇지 못하다.

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

firstName, lastName, street, houseNumber, city, state, zipcode 라는 변수가 있을 때 훝어보면 주소라는 사실을 금방 알아 챈다. 하지만 state 라는 변수 하나만 사용한다면 state가 주소 일부라는 사실을 금방 알아챌 수 없다.

addr이란는 접두어를 붙이면 조금 더 명확해진다. (addrFirstName, addrLastName, addrStreet, addrHouseNumber, addrCity, addrState, addrZipcode) → 물론 Address라는 클래스를 만다는 것이 더 좋다.

불필요한 맥락을 없애라

고급 휘발유 충전소라는 애플리케이션을 짠다고 할 때, 모든 클래스 이름을 GSD로 시작하겠다는 것은 전혀 바람직하지 못한다.

일반적으로 짧은 이름이 긴 이름보다 좋다. (단, 의미가 분명한 경우에 한해서)

마치면서

좋은 이름을 선택하려면 설명 능력이 뛰어나야 하고 문화적인 배경이 같아야 한다.

좋은 이름을 선택하는 능력은 기술, 비즈니스, 관리 문제가 아니라 교육 문제다.

사람들이 이름을 바꾸지 않으려는 이유 하나는 다른 개발자가 반대할까 두려워서다. → 하지만 좋은 이름으로 바꾸면 오히려 반갑고 고맙다.

Sooyeol's box

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