2장. 의미 있는 이름

의도를 분명히 밝혀라

코드 맥락이 코드 자체에 명시적으로 드러나도록 지어야 한다.

변수명 짓기 = 의도가 드러나는 이름 사용하기

그릇된 정보를 피하라

코드에 그릇된 단서를 남겨서는 안되며, 그릇된 단서는 코드 의미를 흐린다.

널리 쓰이는 의미가 있는 단어를 다른 의미로 사용하면 안된다.

예를 들어 여러 계정을 그룹으로 묶을 때, 실제로 List 타입이 아니라면 accountList 라고 명명하면 안된다. 이는 프로그래머에게 그릇된 정보를 제공하기 때문이다. 그러므로 accountGroup, bunchOfAccounts, Accounts 등 으로 명명하는 것이 좋다.

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

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

일관성이 떨어지는 표기법은 그릇된 정보. IDE 자동 완성 기능에서도 글자를 입력할 경우 유사한 개념이 알파벳 순으로 나오는데, 이러한 기능은 개념 차이가 명백히 드러날수록 더욱 유용해진다.

예를 들어 대.소문자 L 이나 대.소문자 O 변수 등은 숫자 1, 숫자 0 과 헷갈리기 쉬운 문자여서, 변수명에 섞어 사용하면 이해하기 힘들어진다.

의미 있게 구분하라

읽는 사람이 차이를 알도록 이름을 지어야 한다.

연속된 숫자를 덧붙이거나 불용어(noise word)를 추가하는 방식은 적절하지 못하다. 이름이 달라야 한다면 의미도 달라야 한다.

예를 들어 a1, a2, ... , an 은 아무런 정보를 제공하지 못하는 이름이며, 저자의 의도가 전혀 드러나지 않는 이름이다.

또한 Product 라는 클래스가 있다고 가정할 때, 다른 클래스를 ProductInfo, ProductData 라고 부른다면 개념을 구분하지 않은 채 이름만 달리하는 상황이 된다.

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

사람들은 단어에 능숙하며, 우리 두뇌에서 상당 부분은 단어라는 개념만 전적으로 처리한다. 또한 정의상으로 단어는 발음이 가능하다.

말을 처리하려고 발달한 두뇌를 활용하기 위해서는 발음하기 쉬운 이름을 선택하자.

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

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

문자 하나만을 사용해서 이름을 짓게 되면 텍스트 코드에서 쉽게 눈에 띄지 않는다.

변수나 상수를 여러 곳에서 사용한다면 검색하기 쉬운 이름이 바람직하다.

인코딩을 피하라

유형이나 범위 정보까지 이름에 넣으면 그만큼 해독하기 어려워진다.

헝가리식 표기법

이름 길이가 제한된 언어를 사용했던 옛날에 사용하던 표기법.

당시에는 컴파일러가 타입을 점검하지 않았으므로, 프로그래머에게 타입을 기억할 단서가 필요했다.

ex) 포트란 - 첫 글자로 유형을 표현, 초창기 베이식 - 글자 하나에 숫자 하나만 허용

멤버 변수 접두어

ex) 멤버 변수에 m_ 라는 접두어 붙이기

이제는 클래스와 함수는 접두어가 필요없을 정도로 작아야 마땅하다. 또한 멤버 변수를 다른 색상으로 표시하거나 눈에 띄게 보여주는 IDE 를 사용해야 마땅하다.

인터페이스 클래스와 구현 클래스

옛날 코드에서 많이 사용하는 접두어 I 는 주의를 흐트리고 과도한 정보를 제공한다.

따라서 인터페이스 클래스와 구현 클래스 이름 중 하나를 인코딩해야 한다면 구현 클래스를 선택하자. ex. SomethingFactoryImpl

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

독자가 코드를 읽으면서 변수 명을 자신이 아는 이름으로 변환해야 한다면 바람직하지 못한 변수 이름이다

문자 하나만 사용하는 변수 이름은 문제가 있지만, 루프에서 반복 횟수를 세는 변수 i, j, k 는 괜찮다. (l 은 절대 안된다. => 아마 헷갈릴 수 있어서 그런 것 같다.)

루프 반복 횟수 변수는 전통적으로 한 글자를 사용하기 때문이다.

전문가 프로그래머는 명료함이 최고 라는 사실을 이해한다. -> 남들이 이해하는 코드를 내놓자.

클래스 이름과 메서드 이름

클래스 이름

• 클래스 이름과 객체 이름은 명사나 명사구가 적합
• 동사는 사용하지 않는다.

메서드 이름

• 메서드 이름은 동사나 동사구가 적합
• 접근자, 변경자, 조건자는 javabean 표준에 따라 값 앞에 get, set, is 를 붙인다.

생성자를 중복정의 할 때는 정적 펙토리 메서드를 사용한다. 이때 메서드는 인수를 설명하는 이름을 사용한다.

// 좋은 코드
val fulcrumPoint = Complex.FromRealNumber(23.0);

// 안 좋은 코드
val fulcrumPoint = Complex(23.0);

만약 생성자 사용을 제한하려면 해당 생성자를 private 으로 선언해서 사용한다.

기발한 이름은 피하라

기발하고 재미난 이름보다는 명료한 이름을 선택하라

의도를 분명하고 솔직하게 표현하자.

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

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

예를 들어, 똑같은 메서드를 클래스마다 fetch, retrieve, get 으로 제각각 부르면 혼란스럽고, 어느 클래스에서 어느 이름을 썼는지 기억하기 힘들다.

마찬가지로 동일 코드 기반에 controller, manager, driver 를 섞어 쓰면 혼란스러워 지는데, 사용자 입장에서는 당연히 클래스도 다르고 타입도 다를 것이라 생각하게 된다.

따라서 일관성 있는 코드를 사용해야 한다.

말장난을 하지 마라

한 단어를 두 가지 목적으로 사용하지 말아야 하며, 다른 개념에 같은 단어를 사용하지 말아야 한다.

예를 들어 add 메서드를 기존 값 두 개를 더하거나 이어서 새로운 값을 만드는데 사용했다고 가정한다. 그런데 새로 작성하는 메서드에서 집합에 값 하나를 추가하기 위해 add 라는 이름을 쓸 경우 기존의 사용 방식과 맥락이 달라진다.

따라서 이러한 경우엔 insert 나 append 라는 이름이 적당하다.

의도를 해독할 책임이 독자에게 있는 것이 아니라, 의도를 밝힐 책임이 저자에게 있도록 하자

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

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

ex) accountVisitor, jobQueue ...

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

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

관련된 개념의 전문가에게 의미를 물어보고 적절한 개념을 사용하는 것이 좋다.

의미 있는 맥락을 추가하라

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

street, city, state, zipcode 라는 변수들을 훑어보면 주소라는 사실을 알 수 있지만, 어느 메서드에서 state 라는 변수 하나만 사용한다면 주소의 일부라는 사실을 알아차리기 힘들다.

그런 상황에는 addr 라는 접두어를 추가해 addrStreet, addrCity, addrState, addrZipcode 처럼 사용하게 되면 맥락이 좀 더 분명해진다.

또한 Address 라는 클래스를 생성하면, 그러한 변수들이 좀 더 큰 개념에 속한다는 사실을 컴파일러에게도 분명히 알려주고 독자들에게도 알려줄 수 있다.

맥락을 개선하면 로직을 쪼개기가 쉬워지므로 알고리즘도 좀 더 명확해진다.

불필요한 맥락을 없애라

예를 들어 고급 휘발유 충전소(Gas Station Deluxe) 라는 애플리케이션을 짠다고 가정할 때, 모든 클래스 이름을 GSD 로 시작하는 것은 바람직하지 않다.

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

Address 클래스

• 인스턴스로 좋은 이름 : accountAddress, customerAddress

• 클래스 이름으로 구분하기 좋은 이름(우편주소, MAC주소, 웹 주소) : PostalAddress, MAC, WebAddress

좋은 이름을 선택하려면 설명 능력이 뛰어나고, 문화적 배경이 같아야 하는데 이것이 사실 제일 어렵다.

코드 이름 개선은 단기적인 효과 뿐만 아니라 장기적인 이익도 보장해준다.