[클린코드] 2장 - 의미 있는 이름

2장 - 의미 있는 이름

의도를 분명히 밝혀라

• 의도가 분명하게 이름을 지으라.
• 변수(함수나 클래스)존재 이유는?, 수행기능은? 사용방법은? 따로 주석이 필요하다면 분명히 드러내지 못했다는 말이다.

그릇된 정보를 피하라

• hp, aix, sco는 변수 이름으로 적합하지 않다. 유닉스 플랫폼이나 유닉스 변종을 가리키는 이름이기 때문이다. 독자에게 그릇된 정보를 제공하면 안된다.
• 일관성이 떨어지는 표기법은 그릇된 정보다.

의미 있게 구분하라

• 컴파일러나 인터프린터만 통과하려는 생각으로 코드를 구현하는 프로그래머는 스스로 문제를 이르킨다.
• 예를 들어 함수의 인자로 a1, a2 보다 source, destination을 사용한다면 코드가 읽기 편해진다.
• NameString보다는 Name으로 사용하여 불용어 중복을 피한다.
• 읽는 사람이 차이를 알도록 이름을 지어라.(message, the message, accountData, account..)

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

• 사람들은 단어에 능숙하다.
• 발음하기 어려운 이름은 토론하기도 어렵다.
• 예
  • private Date genymdhms -> private Data generationTimestamp

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

• 문자 하나를 사용하는 이름과 상수는 텍스트 코드에서 쉽게 눈에 띄지 않는다.
  • MAX_CLASSES_STUDENT vs 7 <- grep으로 어느것이 찾기 더 쉬운가?
• e는 변수 이름으로 적합하지 못하다. e는 영어에서 가장 많이 쓰이는 문자이다.
• 긴 이름이 짦은 이름보다 좋다. 검색하기 쉬운 이름 이 상수보다 좋다.

인코딩을 피하라

• 헝가리식 표기법
  • 헝가리식 표기법이나 기타 인코딩 방식이 오히려 방해가 된다. 변수, 함수 클래스 이름이 타입이 바꾸기 어려워지며 읽기도어려워진다.
  • DWORD dwCount;를 int형으로 변경할 경우, int nCount로 변경되며 변수명도 변경시켜야 하므로 코드가 많이 수정되어야한다.
• 멤버 변수 접두어
  • 멤버 변수에 m_접두어를 붙일 필요도 없다.(똑똑해진 IDE가 해준다)
  • 결국 접두어는 옛날에 작성한 구닥다리 코드라는 징표가 되어 버린다.

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

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

클래스 이름

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

메서드 이름

• 메서드 이름은 동사나 동사구가 적합하다.
  • postPayment, deletePage, save ..

기발한 이름은 피하라

• 이름이 너무 기발하면 저자와 유머 감각이 비슷한 사람만, 그리고 농담을 기억하는 동안만 이름을 기억한다.
  • HolyHandGrenade -> DeleteItems
• 재미난 이름 보다 명료한 이름을 선택하라.

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

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

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

• 코드를 읽는 사람도 프로그래머라는 사실을 명심한다.
• 전산용어, 알고리즘이름, 패턴 이름, 수학 용어 등을 사용해도 괜찮다.

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

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

의미 있는 맥락을 추가하라.

• 스스로 의미가 분명한 이름이 없지 않지만 대다수 이름은 그렇지 못하다
  • firstName, lastName을 addrFirstName, addrLastName으로 바꾸면 주소의 일부라는 것을 쉽게 알 수 있다.

불필요한 맥락을 없애라

• 예를 들어 GDS 회계 모듈에 사용하는 클래스 이름을 GSDAccountAddress로 GDS를 다 붙인다면 다른 고객 관리프로그램에서 사용할 때 적절한가? GDS로 시작하는 클래스는 너무 많아 찾기도 힘들다.
• 일반적으로 짧은 이름이 긴 이름이 좋다. 단, 의미가 분명한 경우에 한해서다. 이름에 불필효한 맥락을 추가하지 않도록 한다.

마치면서

좋은 이름을 선택하려면 설명 능력이 뛰어나야 하고 문화적인 배경이 같아야한다. 이것이 제일 어렵다. 좋은 일므을 선택하는 능력은 기술, 비즈니스, 관리 문제가 아니라 교육의 문제다.