2. 의미 있는 이름

[클린코드 - http://www.yes24.com/Product/Goods/11681152]

 

들어가면서

• 이름을 잘 지으면 여러 모로 편하다

 

의도를 분명히 밝혀라

• 좋은 이름을 지으려면 시간이 걸리지만 좋은 이름으로 절약하는 시간이 훨씬 더 많다
• 변수, 함수, 클래스 이름은 다음 질문에 모두 답해야 한다
  • 변수(혹은 함수나 클래스)의 존재 이유는?
  • 수행 기능은?
  • 사용 방법은?
  • => 따로 주석이 필요하다면 의도를 분명히 드러내지 못했다는 것
• 함축성 -> 코드 맥락이 코드 자체에 명시적으로 드러나지 않으면 코드가 하는 일을 짐작하기 어려움
• 이름만 고쳐도 코드가 하는 일을 이해하기가 쉬워진다

 

그릇된 정보를 피하라

• 나름대로 널리 쓰이는 의미가 있는 단어를 다른 의미로 사용하면 안된다
• 여러 계정을 그룹으로 묶을 때 실제 List가 아니라면 accountList라 명명하지 않는다
  • 실제 컨테이너가 List인 경우라도 컨테이너 유형을 이름에 넣지 않는 편이 바람직하다
• 서로 흡사한 이름을 사용하지 않도록 주의한다
• 유사한 개념은 유사한 표기법을 사용한다
  • 일관성이 떨어지는 표기법은 그릇된 정보다
• 소문자 L 이나 대문자 O 는 혼란을 야기하니 주의하자

 

의미 있게 구분하라

• 연속된 숫자를 덧붙이거나 불용어(noise word)를 추가하는 방식은 아무런 정보를 제공하지 못하기 때문에 적절하지 않다
• 읽는 사람이 차이를 알도록 이름을 지어라

 

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

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

 

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

• 문자 하나를 사용하는 이름과 상수는 텍스트 코드에서 쉽게 눈에 띄지 않는다
  • 상수는 검색하기 매우 힘들다
    => 검색하기 쉬운 이름이 상수보다 좋다
  • e는 영어에서 가장 많이 쓰이는 문자라 변수 이름으로 적합하지 못하다
    => 이런 관점에서 긴 이름이 짧은 이름보다 좋다
• 이름 길이는 범위 크기에 비례해야 한다
  • 간단한 메서드에서 로컬 변수만 한 문자를 사용

 

인코딩을 피하라

• 문제 해결에 집중하는 개발자에게 인코딩은 불필요한 정신적 부담이다
• 헝가리식 표기법
  • 예전에는 언어 특성이나 컴파일러의 제약으로 프로그래머에게 타입을 기억할 단서가 필요했다
  • 요즘 언어는 많은 타입을 지원하고 IDE도 잘 되어 있다
  • 헝가리식 표기법이나 기타 인코딩 방식이 오히려 방해가 된다
    • 변수, 함수, 클래스 이름이나 타입을 바꾸기가 어려워지며 읽기가 어려워지고 독자를 오도할 가능성도 커진다
• 멤버 변수 접두어
  • 멤버 변수에 m_이라는 접두어는 필요 없다
  • 클래스와 함수는 접두어가 필요없을 정도로 작아야 마땅하다
• 인터페이스 클래스와 구현 클래스
  • 인터페이스와 구현 클래스가 존재할 때 인터페이스 이름은 접두어를 붙이지 않는 편이 좋다

 

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

• 독자가 코드를 읽으면서 변수 이름을 자신이 아는 이름으로 변환해야 한다면 그 변수 이름은 바람직하지 못하다
• 문자 하나만 사용하는 변수 이름은 문제가 있다
  • 루프에서 반복 횟수를 세는 변수 i, j, k는 괜찮다(l은 절대xxx)
• 전문가 프로그래머는 명료함이 최고라는 사실을 이해한다

 

클래스 이름

• 클래스 이름과 객체 이름은 명사나 명사구가 적합하다
  • Manager, Processor, Data, Info 등과 같은 단어는 피한다
  • 동사는 사용하지 않는다

 

메서드 이름

• 메서드 이름은 동사나 동사구가 적합하다
• 점근자(Accessor), 변경자(Mutator), 조건자(Predicate)는 javabean 표준에 따라 값 앞에 get, set, is를 붙인다
• 생성자(Constructor)를 중복정의(overload)할 때는 정적 팩토리 메서드를 사용한다
  • 메서드 이름은 인수를 설명하는 이름을 사용한다
    ex) Complex fulcrumPoint = Complex.FromRealNuber(23.0) 이
          Complex fulcrumPoint = new Complex(23.0) 보다 낫다
  • 생성자 사용을 제한하려면 해당 생성자를 private로 선언

 

기발한 이름은 피하라

• 재미난 이름보다 명료한 이름을 선택하라
• 특정 문화에서만 사용하는 농담은 피하는 편이 좋다
• 의도를 분명하고 솔직하게 표현하라

 

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

• 추상적인 개념 하나에 단어 하나를 선택해 이를 고수한다
• 메서드 이름은 독자적이고 일관적이어야 한다
• 일관성 있는 어휘는 코드를 사용할 프로그래머가 반갑게 여길 선물이다

 

말장난을 하지 마라

• 한 단어를 두 가지 목적으로 사용하지 마라
  • ex) add라는 단어를 기존 값 두개를 더하거나 이어서 새로운 값을 만드는데에 사용하다가 집합에 값 하나를 추가하는 메서드 이름을 add를 넣어 짓는 것은 적절하지 못하다. insert나 append가 적합하다
• 프로그래머는 코드를 최대한 이해하기 쉽게 짜야 한다
  => 집중적인 탐구가 필요한 코드가 아니라 대충 훑어봐도 이해할 코드 작성이 목표다

 

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

• 기술 개념에는 기술 이름이 가장 적합한 선택이다
• 모든 이름을 문제 영역(domain)에서 가져오는 정책은 현명하지 못하다

 

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

• 적절한 '프로그래머 용어'가 없다면 문제 영역에서 이름을 가져온다
• 우수한 프로그래머와 설계자라면 해법 영역과 문제 영역을 구분해서 어느 영역의 이름이 적절한지 판단해야 한다

 

의미 있는 맥락을 추가하라

• 의미가 분명하지 못한 이름은 클래스, 함수, 이름 공간에 넣어 맥락을 부여한다
• 모든 방법이 실패하면 마지막 수단으로 접두어를 붙인다

 

불필요한 맥락을 없애라

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

 

마치면서

• 좋은 이름을 선택하려면 설명 능력이 뛰어나야 하고 문화적인 배경이 같아야 한다
• 이름을 나름대로 바꿨다가는 누군가 질책할지도 모르지만 그렇다고 코드를 개선하려는 노력을 중단해서는 안 된다
• 다른 사람이 짠 코드를 손본다면 리팩터링 도구를 사용해 문제 해결 목적으로 이름을 개선하라