[Clean Code] 2장 의미 있는 이름

 

 

들어가면서

소프트웨어에서 이름은 어디에나 쓰인다.

이렇게 많이 사용하므로 이름을 잘 지으면 편하다.

이 장에서는 이름을 잘 짓는 간단한 규칙을 소개한다.

 

 

 

#1, 의도를 분명히 밝혀라

의도가 분명한 이름은 정말로 중요하다.

좋은 이름을 짓는건 시간이 걸리지만 이것으로 절약하는 시간이 훨씬 많다.

따로 주석이 필요하다면 의도를 분명히 드러내지 못했다는 말이다.

1번처럼 아무 의미가 없는 변수명이라면 주석으로 설명해야한다.

하지만 2번처럼 의도가 드러나는 이름을 사용하면 코드 이해와 변경이 쉬워진다.

 

왼쪽 코드는 복잡한 문장은 없지만 무슨 기능인지 짐작할 수 없다.

여기서 문제는 단순성이 아니라 함축성이다. 코드 맥락이 코드 자체에 명시적으로 드러나지 않는다.

그래서 사전 정보가 필요하다.

 

하지만 오른쪽 코드같은 경우 무슨 기능인지 또는 어떤 개념인지 이름만 붙였을 뿐인데 어느정도 짐작이 가능해졌다.

즉, 코드의 단순성은 변하지 않아도 코드는 더욱 명확해졌다.

 

단순히 이름만 고쳐도 함수가 하는 일을 이해하기 쉬워진다.
바로 이것이 좋은 이름이 주는 위력이다.

 

 

 

#2, 그릇된 정보를 피하라

프로그래머는 코드에 그릇된 단서를 남겨서는 안된다.

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

(e.g. 노트북을 데스크탑이라는 의미로 쓴다면 엄청나게 헷갈리지 않겠는가?)

계정을 담는 컨테이너가 실제 List가 아닌데 accountList라고 짓는다면 프로그래머에게 그릇된 정보를 제공하는 셈이다.

 

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

(e.g. XYZControllerForEfficientHandlingOfStrings, XYZControllerForEfficientStorageOfStrings 이 두가지의 차이점 바로 알겠는가?)

 

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

일관성이 떨어지는 표기법은 그릇된 정보이다.

위와 같이 소문자 L 이나 대문자 O, 숫자 1 이나 숫자 0은 매우 혼동하기 쉬우므로 쓰는 것을 주의해야한다.

이럴 경우 주의하라고 주석을 적거나 다른 개발자에게 알려야하는데 이것도 결국 이름만 바꾸면 문제가 깨끗이 풀린다.

 

그릇된 정보인 이름을 사용하지 않는다.

 

 

 

#3, 의미 있게 구분하라

컴파일러나 인터프리터만 통과하려는 생각으로 코드를 구현하는 프로그래머는 스스로 문제를 일으킨다.

컴파일러를 통과하더라도 연속된 숫자나 불용어를 추가하는 방식은 적절하지 못하다.

이름이 달라야 한다면 의미도 달라져야 한다.

연속적인 숫자나 불용어를 덧붙인 이름은 그릇된 정보를 제공하는 이름도 아니며, 아무런 정보를 제공하지 못하는 이름이다.

(a1, a2, a3 ... ) , (Product 클래스, ProductInfo 클래스, ProductData 클래스)

결국 명확한 관례가 없다면 구분할 수가 없다.

 

읽는 사람이 차이를 알도록 이름을 지어라.

 

 

 

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

발음하기 쉬운 이름은 중요하다. 프로그래밍은 사회 활동이기 때문이다.

첫번째 클래스와 두번째 클래스를 설명한다고 생각해보면 바로 와닿을 것이다.

 

발음하기 쉬운 이름은 중요하다.
프로그래밍은 사회 활동이다.

 

 

 

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

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

이런 관점에서 긴 이름이 짧은 이름보다 좋다.

2번 함수처럼 이름을 의미있게 지으면 함수가 길어진다.

하지만 이 함수에서 result(결과값)을 찾기가 얼마나 쉬운가?

1번처럼 쓴다면 result를 찾기위해 함수코드를 전부 읽어서 찾아내야 할 것이다.

지금이야 간단해서 알아보지만 만약에 코드가 많고 다른 이름을 찾으려면 해당하는 이름을 모두 찾아 분석해야 할 것이다.

 

이름 길이는 범위 크기에 비례해야 한다.
여러 곳에서 사용한다면 검색하기 쉬운 이름이 바람직하다.

 

 

 

#6, 인코딩을 피하라

인코딩한 이름은 거의 발음하기 어렵고 오타가 생기기 쉽다.

객체는 강한 타입이고, IDE는 발전했으므로 자바 프로그래머는 변수 이름에 타입을 인코딩할 필요가 없다.

헝가리식 표기법

클래스와 함수는 접두어가 필요 없을 정도로 작아야하고,  IDE로 멤버 변수를 눈에 띄게 보여주자.

멤버 변수 접두어

1번엔 멤버 변수임을 가르쳐주려고 m_ 이라는 접두어를 붙였다.

하지만 IDE로 눈에 띄게 표시해주므로 2번처럼 접두어를 없앴다.

 

인터페이스 클래스 이름과 구현 클래스 이름 중 하나를 인코딩해야 한다면 구현 클래스 이름을 선택하라.

• 인터페이스 클래스 : ShapeFactory
• 구현 클래스 : ShapeFactoryImp

 

 

 

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

문자 하나만 사용하는 변수 이름은 문제가 있다.

(루프에서 반복 횟수를 세는 변수는 괜찮으나 여기서도 소문자 L은 안된다)

전문가 프로그래머는 명료함이 최고라는 사실을 이해한다.

전문가 프로그래머는 자신의 능력을
좋은 방향으로 사용해 남들이 이해하는 코드를 내놓는다.

 

 

 

#8, 클래스 이름

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

(좋은 예 : Customer, WikiPage, Account, AddressParser 등)

Manager, Processor, Date, Info 등과 같은 단어와 동사는 사용하지 않는다.

 

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

 

 

 

#9, 메서드 이름

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

(좋은 예 : postPayment, deletePage, save 등)

접근자 Accessor, 변경자 Mutator, 조건자 Predicate 는 javabean 표준에 따라 값 앞에 get, set, is 를 붙인다.

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

정적 팩토리 메서드는 객체 생성 역할을 하는 메서드이다.

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

이렇게 생성자 사용을 제한하려면 해당 생성자를 private로 하면 1번의 경우 생성이 불가능하다.

그리고 정적 팩토리 메서드로 생성하려면 2번처럼 하면 생성된다.

1번 코드보다 2번 코드가 좋은 예시이다.

 

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

 

 

 

#10, 기발한 이름은 피하라

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

특정 문화에서만 사용하는 농담도 피하는 것이 좋다.

 

재미난 이름보다 명료한 이름을 선택하라.
의도를 분명하고 솔직하게 표현하라.

 

 

 

#11, 한 개념에 한 단어를 사용하라

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

(e.g. 똑같은 메서드를 클래스마다 fetch, retrieve, get 으로 부르면 혼란스럽다)

(e.g. controller, manager, driver)

메서드 이름은 독자적이고 일관적이어야 한다. 그래야 주석을 보지않아도 프로그래머가 올바른 메서드를 선택한다.

 

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

 

 

 

#12, 말장난을 하지 마라

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

다른 개념에 같은 단어를 사용하면 그것은 말장난에 불과하다.

 

프로그래머는 코드를 최대한 이해하기 쉽게 짜야한다.
집중적인 탐구가 필요한 코드가 아니라 대충 훑어봐도 이해할 코드 작성이 목표이다.

 

 

 

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

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

모든 이름을 문제 영역(domain)에서 가져오진 않는다.

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

 

 

 

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

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

문제 영역 개념과 관련이 깊은 코드라면 문제 영역에서 이름을 가져와야 한다.

 

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

 

 

 

#15, 의미 있는 맥락을 추가하라

클래스, 함수, 이름 공간에 넣어 맥락을 부여한다.

모든 방법이 실패하면 마지막 수단으로 접두어를 붙인다.

왼쪽 함수가 맥락이 불분명한 변수이고, 오른쪽 클래스가 맥락이 분명한 변수이다.

맥락이 불분명하면 함수를 끝까지 보고 파악해 유추해내야하며, 그냥 훑기만해서는 세 변수의 의미를 알 수 없다.

하지만 이 함수는 여러 기능을 복합적으로 하고 있으므로 쪼개서 오른쪽 클래스로 만들었다.

그렇기에 이 세 변수는 맥락이 분명해졌고 알고리즘도 좀 더 명확해졌다.

단순히 코드의 길이와 함축성만으로 코드가 깔끔하다라고 생각하면 안된다.

지금껏 우리가 읽어와서 알듯이 단순하게 함축하더라도 독자가 이해하지 못한다면? 그건 깨끗한 코드가 아니다.

 

 

 

 

#16, 불필요한 맥락을 없애라

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

이름에 불필요한 맥락을 추가하지 않도록 주의한다.

(e.g. accountAddress와 customerAddress는 Address 클래스 인스턴스로는 좋은 이름이나 클래스 이름으로는 적합하지 않다)

 

잠깐 #5, 검색하기 쉬운 이름을 사용하라 에서 긴 이름이 짧은 이름보다 좋다고하지 않았는가?

#5에서 말한 것은 함수 이름을 문자 하나만 사용하여 짧게 작성한 것 보다

이름을 의미있게 짓고 알아보기 쉽게 만들라는 의미였다.

 

여기서 짧은 이름이 좋다는 것은 예를 들면 'School' 앱을 작성할 때 모든 클래스 이름을 Sch로 시작하겠다는 생각은 하지 말라는 뜻이다.

만약 회계 모듈이 있다면 SchAccountAddress 클래스가 되는 것인데 이럴 경우 긴 이름보다 짧은 이름이 낫다는 것이다.

 

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

 

 

 

#17, 마치면서

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

이름을 바꾸면 누군가 질책할지 모른다는 두려움이 있지만, 그렇다고 코드를 개선하려는 노력을 중단해서는 안된다.

 

다른 사람이 짠 코드를 손본다면 리팩터링 도구를 사용해 문제 해결 목적으로 이름을 개선하라.
단기적인 효과는 물론 장기적인 이익도 보장한다.

 

 

 

---

Clean Code / 로버트 C.마틴 지음 / 박재호, 이해영 옮김 / 인사이트