📌 의미 있는 이름

의도를 분명히 밝혀라

• "의도가 분명하게 이름을 지으라"
• 변수나 함수 그리고 클래스 이름은 다음과 같은 질문에 모두 답해야 한다.
  → 변수(혹은 함수나 클래스)의 존재 이유는?
  → 수행 기능은?
  → 사용 방법은?
  → 따로 주석이 필요하다면 의도를 분명히 드러내지 못했다는 말이다.
• 코드 맥락이 코드 자체에 명시적으로 드러나야 한다.

그릇된 정보를 피하라

• 그릇된 단서는 코드 의미를 흐린다.
• 나름대로 널리 쓰이는 의미가 있는 단어를 다른 의미로 사용해도 안 된다.
• 일관성이 떨어지는 표기법은 그릇된 정보다.

의미 있게 구분하라

• 동일한 범위 안에서는 다른 두 개념에 같은 이름을 사용하지 못한다. 그래서 프로그래머가 한쪽 이름을 마음대로 바꾸고픈 유혹에 빠진다.
• 컴파일러를 통과할지라도 연속된 숫자를 덧붙이거나 불용어를 추가하는 방식은 적절하지 못하다.
• 이름이 달라야 한다면 의미도 달라져야 한다.
• 불용어를 추가한 이름 역시 아무런 정보도 제공하지 못한다.
• Product라는 클래스가 있는데 다른 클래스 이름을 ProductInfo 혹은 ProductData라 부른다면 개념을 구분하지 않은 채 이름만 달리한 경우다.

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

• 발음하기 어려운 이름은 토론하기도 어렵다.
• genymdhms(generate date, year, month, day, hour, second)라는 단어 대신 generationTimestamp를 사용하면 지적인 대화가 가능해진다.

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

• 문자 하나를 사용하는 이름과 상수는 텍스트 코드에서 쉽게 눈에 띄지 않는다는 문제점이 있다.
• 긴 이름이 짧은 이름보다 좋다.
• 검색하기 쉬운 이름이 상수보다 좋다.
• 이름 길이는 범위 크기에 비례해야 한다.
• 변수나 상수를 코드 여러 곳에서 사용한다면 검색하기 쉬운 이름이 바람직하다.

인코딩을 피하라

• 유형이나 범위 정보까지 인코딩에 넣으면 그만큼 이름을 해독하기 어려워진다.
• 인코딩한 이름은 거의가 발음하기 어려우며 오타가 생기기도 쉽다.

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

• 코드를 읽으면서 변수 이름을 자신이 아는 이름으로 변환해야 한다면 그 변수 이름은 바람직하지 못하다.
• 문자 하나만 사용하는 변수 이름은 문제가 있다. 루프에서 반복 횟수를 세는 변수 i, j, k는 괜찮다.
• 똑똑한 프로그래머와 전문가 프로그래머 사이에서 나타나는 차이점 하나만 들자면, 전문가 프로그래머는 명료함이 최고라는 사실을 이해한다.
• 전문가 프로그래머는 자신의 능력을 좋은 방향으로 사용해 남들이 이해하는 코드를 내놓는다.

클래스 이름

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

메서드 이름

• 메서드 이름은 동사나 동사구가 적합하다.
• 접근자: get
• 변경자: set
• 조건자: is

기발한 이름은 피하라

• 특정 문화에서만 사용하는 농담은 피하는 편의 좋다.
• 의도를 분명하고 솔직하게 표현하라

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

• 추상적인 개념 하나에 단어 하나를 선택해 이를 고수한다.
• 똑같은 메서드를 클래스마다 fetch, retrieve, get으로 제각각 부르면 혼란스럽다.
• 일관성 있는 어휘는 코드를 사용할 프로그래머가 반갑게 여길 선물이다.

말장난을 하지 마라

• 한 단어를 두 가지 목적으로 사용하지 마라.
• 여러 클래스에 add라는 메서드가 생겼다. 지금까지 구현한 add 메서드는 모두가 기존 값 두 개를 더하거나 이어서 새로운 값을 만든다고 가정하자. 새로 작성하는 메서드는 집합에 값 하나를 추가한다. 이 메서드를 add라 불러도 괜찮을까? 새 메서드는 기존 add 메서드와 맥락이 다르다. 그러므로 insert나 append라는 이름이 적당하다.
• 프로그래머는 코드를 최대한 이해하기 쉽게 짜야 한다.

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

• 전산 용어, 알고리즘 이론, 패턴 이름, 수학 용어 등을 사용해도 괜찮다.
• 모든 이름을 문제 영역에서 가져오는 정책은 현명하지 못하다.
• 기술 개념에는 기술 이름이 가장 적합한 선택이다.

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

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

의미 있는 맥락을 추가하라

• firstName, lastName, street, houseNumber, city, state, zipcode라는 변수가 있다. 변수를 훑어보면 주소라는 사실을 금방 알아챈다. 하지만 어느 메서드가 state라는 변수 하나만 사용한다면?
• addr라는 접두어를 추가해 addrFirstName, addrLastName, addrState라 쓰면 맥락이 좀 더 분명해진다. 물론 Address라는 클래스를 생성하면 더 좋다.
• 맥락을 개선하면 함수를 쪼개기가 쉬워지므로 알고리즘도 좀 더 명확해진다.

불필요한 맥락을 없애라

• 이름에 불필요한 맥락을 추가하지 않도록 주의한다.
• accountAddress와 customerAddress는 Address 클래스 인스턴스로는 좋은 이름이나 클래스 이름으로는 적합하지 못하다. Address는 클래스 이름으로 적합하다.

마치면서

• 좋은 이름을 선택하려면 설명 능력이 뛰어나야 하고 문화적인 배경이 같아야 한다.
• 다른 사람이 짠 코드를 손본다면 리팩터링 도구를 사용해 문제 해결 목적으로 이름을 개선하라.

---

📘 코딩을 할 때 쉬운 것 같으면서 어려운 일이 변수, 함수 네이밍이다. 이름만 잘 지어도 코드의 질은 훨씬 높아진다는 것을 오늘 내용을 읽으며 다시금 깨달았다. 반성하자면, 이름에 정보가 드러나지 않은 채 나만 아는 단어나 문자로 이름을 붙인 적이 많다. 이름을 잘 설정한다면 주석 처리를 하지 않고도 코드를 읽었을 때 이해가 잘될 것이다. 코드만 이해하기 쉽게 짜는 것이 아닌, 이름도 이해하기 쉽게 짜야 할 것이다. 오늘 내용을 바탕으로 네이밍에 조금 더 주의를 기울여보자!