의미 있는 이름

• 의도를 분명히 밝혀라
• 그릇된 정보를 피하라
  • hp, aix, sco는 변수 이름으로 적합하지 않다. 유닉스 플랫폼이나 유닉스 변종을 가리키는 이름이기 때문이다.
  • List라는 단어보다는 Group이나 복수 형태의 s를 붙이는 것이 낫다.
  • 서로 흡사한 이름을 사용하지 않는다.
  • 유사한 개념은 유사한 표기법을 사용한다. 일관성이 떨어지는 표기법은 그릇된 정보다.
  • 소문자 L이나 대문자 O는 1과 0처럼 보일 수 있어 피해야 한다.
• 의미 있게 구분하라
  • 연속된 숫자를 덧붙이거나 불용어를 추가하는 방식은 적절하지 못하다. 이름이 달라야 한다면 의미도 달라져야 한다.
  • 변수 이름에 variable이라는 단어는 사용하지 말아야 한다.
  • 읽는 사람이 차이를 알도록 이름을 지어야 한다.
• 발음하기 쉬운 이름을 사용하라
• 검색하기 쉬운 이름을 사용하라
• 인코딩을 피하라
  • 멤버 변수 접두어를 붙일 필요도 없다.
• 자신의 기억력을 자랑하지 마라
  • 독자가 코드를 읽으면서 변수 이름을 자신이 아는 이름으로 변환해야 한다면 그 변수 이름은 바람직하지 못하다.
  • 명료해야 한다. 자신의 능력을 좋은 방향으로 사용해 남들이 이해하는 코드를 내놓아야 한다.
• 클래스 이름
  • 클래스 이름과 객체 이름은 명사나 명사구가 적합하다.
  • 동사는 사용하지 않는다.
• 메서드 이름
  • 메서드 이름은 동사나 동사구가 적합하다.
  • 접근자, 변경자, 조건자는 javabean 표준에 따라 값 앞에 get, set, is를 붙인다.
  • 생성자를 중복정의할 때는 정적 팩터리 메서드를 사용한다.
  • 메서드는 인수를 설명하는 이름을 사용한다.
• 기발한 이름은 피하라
  • 이름이 너무 기발하면 저자와 유머 감각이 비슷한 사람만, 그리고 농담을 기억하는 동안만, 이름을 기억한다.
  • 의도를 분명하고 솔직하게 표현해야 한다.
• 한 개념에 한 단어를 사용하라
  • 추상적인 개념 하나에 단어 하나를 선택해 이를 고수한다.
  • 메서드 이름은 독자적이고 일관적이어야 한다. 그래야 주석을 뒤져보지 않고도 프로그래머가 올바른 메서드를 선택한다.
• 말장난을 하지 마라
  • 한 단어를 두 가지 목적으로 사용하지 마라.
  • 다른 개념에 같은 단어를 사용한다면 그것은 말장난에 불과하다.
• 해법 영역에서 가져온 이름을 사용하라
  • 전산 용어, 알고리즘 이름, 패턴 이름, 수학 용어 등을 사용해도 괜찮다.
  • 모든 이름을 문제 영역(domain)에서 가져오는 정책은 현명하지 못하다. 같은 개념을 다른 이름으로 이해하던 동료들이 매번 고객에게 의미를 물어야하기 때문이다.
  • 프로그래머에게 익숙한 기술 개념은 아주 많다. 기술 개념에는 기술 이름이 가장 적합한 선택이다.
• 문제 영역에서 가져온 이름을 사용하라
  • 적절한 ‘프로그래머 용어’가 없다면 문제 영역에서 이름을 가져온다.
• 의미 있는 맥락을 추가하라
  • 스스로 의미가 분명한 이름이 없지 않다. 하지만 대다수 이름은 그렇지 못하다. 그래서 클래스, 함수, 이름 공간에 넣어 맥락을 부여한다. 모든 방법이 실패하면 마지막 수단으로 접두어를 붙인다.
  • 맥락을 개선하면 함수를 쪼개기가 쉬워지므로 알고리즘도 좀 더 명확해진다.
• 불필요한 맥락을 없애라
  • 일반적으로는 짧은 이름이 긴 이름보다 좋다. 단, 의미가 분명한 경우에 한해서다. 이름에 불필요한 맥락을 추가하지 않도록 주의해야 한다.
  • ‘고급 휘발유 충전소(Gas Sattion Deluxe)’라는 애플리케이션을 짠다고 모든 클래스 이름을 GSD로 시작하겠다는 생각은 버려야 한다.

결론

좋은 이름을 선택하려면 설명 능력이 뛰어나야 하고 문화적인 배경이 같아야 한다. 이것이 제일 어렵다. 여느 코드 개선 노력과 마찬가지로 이름 역시 나름대로 바꿨다가는 누군가 질책할지도 모른다고 두려워하지 말고 코드를 개선하려는 노력을 중단해서는 안 된다.

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