2장. 의미 있는 이름

들어가면서

• 소프트웨어의 모든 구성요소는 이름을 가지고 있다. 클래스, 메서드, 변수, 인자, 패키지, 파일 이름 등 모든 것들이 이름을 지니고 있다.
• 즉, 코드의 어느 부분을 읽어도 이름을 읽을 수 있다.
• 그렇다면, 좋은 이름을 짓는다면 코드를 읽는 행위 자체가 편리해지지 않을까? 좋은 이름을 짓는 것은 그래서 중요하다.

그릇된 정보를 피하라

• 이름에는 그릇된 정보가 담기면 안 된다. 이름은 그 이름에 담긴 코드들을 대표하는 정보다. 초등학생들이 다니는 학교 이름이 ㅇㅇ 고등학교이면, 당연히 혼란이 오기 마련이다.
• 널리 쓰이는 의미가 있는 단어를 다른 의미로 사용하면 안 된다. 읽는 사람이 단어의 의미가 자기가 알고 있는 의미인지, 새로운 의미인지 헷갈린다.
• 서로 흡사한 이름을 사용하지 말자. 비슷한 이름을 여러 개 두는 것은, 코드를 읽는 사람이 개발이 아니라 틀린 그림 찾기를 하게 만든다.
  • 비슷한 이름을 가진 객체가 여러 개 있다면, 객체를 잘못 구분한 것은 아닌지 의심해 보자.
• 유사한 개념은 유사한 표기법을 사용하자. 표기법은 유사하지만, 그 개념은 명확하게 다른 이름이라면 사용이 용이하다.

의미 있게 구분하라

• 이름이 다르다면, 그 의미도 달라야 한다. 이름이 달라 컴파일링이 될지라도, 이름에 의미가 담겨있지 않다면 올바르지 못 한 명명이다.
• 연속적으로 숫자를 붙이는 이름(a1, a2, a3 ... )은 적절하지 못하다.
• 큰 의미가 없는 단어들로 이름을 구분하는 것은 적절하지 못하다. ProductInfo와 ProductData 클래스는 각 클래스가 어떤 역할을 하는지 구분해주지 못한다.
• 가급적 관사 접두어를 사용하지 말자. 그러니까, customer가 있다고 theCustomer를 사용하는 것은 옳지 않다.
• 결국, 코드를 읽는 사람이 이름만으로 그 차이를 알 수 있게 의미 있는 이름으로 구분해야 한다.

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

• 발음하기 어려운 이름은 소통에 어려움을 만든다. 그래서 발음하기 쉬운 이름은 중요하다. 개발은 혼자 하는 일이 아니다.
• 사실 발음하기 어려운 이름이 되는 이유는 축약어를 사용하게 되는 경우가 많아서다. 발음하기 어려운 축약어를 사용할바에는 좀 길어도 이름을 풀어쓰자.

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

• 한 문자로 이름 지어진 변수나 상수는 검색이 어렵다. 물론, 읽기도 어렵다. 이름이 의미하는 바를 한눈에 알기 어렵기 때문이다.
• 마찬가지로, 매직 넘버를 직접 사용하는 것도 검색이 어렵다. 20을 직접 사용하는 것 보다는 DISCOUNT_RATE라는 상수를 만들어 사용하는 편이 낫다.
• 이러한 관점에서, 긴 이름이 짧은 이름보다 낫고, 검색하기 쉬운 이름이 매직넘버를 직접 사용하는 것보다 낫다.
  • 그러나 이름 길이는 범위 크기에 비례해야 한다. 예를 들어, User 클래스 내부에 있는 name은 의미가 명확하다. 하지만 다른 클래스에서 사용한다면 buyerName, sellerName과 같이 구분되어야 한다.

인코딩을 피하라

- 헝가리식 표기법 : 사용하지 말자

• 아주 에전에는 데이터 타입에 따른 접두어를 이름 앞에 붙여야 했다. 그러나 지금은 사용하지 않는다.

- 멤버 변수 접두어 : 사용하지 말자

• 예전에는 멤버 변수 앞에 m_이라는 접두어를 사용했다. 그러나 지금은 사용하지 않는다.

- 인터페이스 클래스와 구현 클래스 : 구분해야 한다

• 추상 클래스와 구현 클래스는 엄연히 구분해야 한다.
• 둘 중 구현 클래스의 이름에 구분자를 붙이자. 예를 들어, CustomerService / CustomerServiceImpl과 같은 식으로 말이다.

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

• 자신이 기억한다고 해서 굳이 이름을 축약해서 사용하거나 다른 의미로 바꿔서 사용하지 말자. 작성한 코드를 읽는 사람은 그 기억이 없다.
• 결국, 이름은 명료한 것이 최고다.

클래스 이름과 메서드 이름

• 클래스 이름은 명사나 명사구로 작성하자. 클래스는 구성틀이다.
• 메서드는 동사나 동사구로 작성하자. 메서드는 기능이다.
• 생성자 메서드를 여러 개 만들어야 한다면, 오버로딩 보다는 정적 팩터리 메서드를 사용하자.

기발한 이름은 피하라

• 이상한 장난치지 말고, 제대로 코딩하자.

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

• 추상적인 개념 하나에는 단어 하나를 선택하고 이를 고수한다.
• 같은 개념인데, 클래스마다 다른 단어를 사용한다면 읽는 사람의 입장에서 다른 개념으로 혼동하기 쉽다.
  • 예를 들어, buy / purchase / take로 클래스마다 다르게 쓴다면 기능에 대해 이해하는 시간이 필요하다.
• 메서드 이름은 독자적이고 일관적이어야 한다. 그래야 주석을 보지 않고도 올바르게 메서드를 선택할 수 있다.

말장난을 하지 마라

• 한 단어를 여러 목적으로 사용하면 안 된다. 하는 일이 비슷하더라도 그 개념이 다르다면 다른 단어로 표현해야 한다.
• 예를 들어 숫자를 더하는 메서드에 add를 사용했다면, 문자열에 단어를 더하는 메서드는 append를 사용하자.
• 서로 다른 개념에 같은 단어를 사용하는 것은 말장난에 불과하다. 이름의 의도는 독자가 해석하는 것이 아니라, 저자가 밝혀야 한다.

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

• 모든 이름을 도메인 영역에서만 가져오는 것은 옳지 않다. 같은 개념을 다르게 이해할 수 있기 때문이다.
• 예를 들어, MVC패턴에 익숙한 개발자라면 CustomerService라는 클래스 이름을 쉽게 이해할 수 있다. 기술 개념에는 기술 이름이 가장 적합하다.

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

• 적절한 개발 용어가 없다면 도메인 영역에서 단어를 가져오자.
• 우리는 결국 문제를 해결하고자 한다. 도메인 영역에서 가져온 이름을 적절히 사용해야 해당 이름을 가진 구성요소의 역할을 쉽게 파악할 수 있다.
• 해법 영역과 문제 영역에서 적절히 이름을 가져오자.

의미 있는 맥락을 추가하라

• 모든 이름을 단어만으로 의미 있게 만들 수는 없다. 이럴 때는 이름에 의미 있는 맥락을 추가해 주자.
• 앞서 언급한 buyerName, sellerName의 buyer와 seller는 '누구의' 이름인지를 명시적으로 표기해 맥락을 추가해 준다.

불필요한 맥락을 없애라

• 그렇다고 불필요하게 여러 맥락을 추가할 필요는 없다. 이렇게 추가된 맥락은 되려 코드를 읽기 어렵게 만들 뿐이다.