Clean Code 2장 - 의미있는 이름

의도를 분명하게 지어라

• 시간이 오래걸리더라도 좋은 이름을 짓는 것이 중요하다.
• 의미 없는 이름으로 변수, 함수, 클래스 이름을 짓는다면 아주 간단한 코드라도 코드를 읽는 사람을 힘들게 한다.

그릇된 정보를 피하라

• 독자가 변질된 정보로 읽을 수 있는 네이밍은 피한다.
• 유사한 개념에선 유사한 표기법을 사용한다. 일관성이 떨어지는 것도 그릇된 정보이다.

의미있게 구분하라

• 컴파일러나 인터프리터만 통과하려는 생각으로 구현하는 프로그래머는 스스로 문제를 일으킨다.
• 연속적인 숫자를 붙이 이름은 적절하지 않다. (n1, n2, n3, …mN)
• 이름이 달라야 한다면 의미도 달라져야 한다.
  • ~Info, ~Data, ~String 등과 같이 특별한 의미를 담고 있지 않은 불용어는 사용하지 않는다.

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

• 발음하기 어려운 이름은 토론하기도 어렵다.
• 즉, 프로그래밍은 사회활동이다.

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

• 문자 하나를 이용하는 이름과 상수는 텍스트 코드에서 쉽게 눈에 띄지 않는다.
• 이런 관점에서 긴 이름이 짧은 이름보다 낫다. - 검색하기 쉽기 때문
• 변수나 상수의 사용 범위는 이름 길이와 비례해야 한다. - bob 의견

인코딩을 피하라

• 인코딩한 이름은 발음이 어렵고, 오타가 발생할 여지가 많다.

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

• 독자가 코드를 읽으며 본인만의 이름으로 변환한다면 변수 이름은 바람직하지 못한 것이다.
• 명료함이 최고임.

클래스 이름

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

메소드 이름

• 메소드 이름은 동사나 동사구가 적합하다.
• 생성자(constructor)를 중복정의(overloading)할 경우엔 정적 팩토리 메소드를 사용한다.

기발한 이름은 피하라

• 재미나고 기발한 이름보다 의미를 명확히 알 수 있는 이름을 택한다.

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

• 똑같은 메소드를 클래스마다 get, fetch, retrieve 등 제각각 부르면 혼란을 야기할 수 있다.
• 주석을 뒤져보지 않고 프로그래머가 올바른 메소드를 사용할 수 있도록 해야한다.

말장난을 하지마라

• 한 단어를 두 가지 목적으로 사용하지 않는다.
• ex) add, append, insert - 비슷하지만 목적이 다른 메서드
• 최대한 이해하기 쉽게 코딩해야한다.
• 집중적인 탐구가 필요한 코드가 아닌 대충 훑어봐도 이해할 수 있는 코드를 작성해야 한다.

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

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

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

• 적절한 프로그래밍 용어가 없다면 문제 영역에서 이름을 가져온다.
• 코드를 유지보수하는 프로그래머는 분야 전문가에게 의미를 물어 파악할 수 있다.

의미있는 맥락을 추가하라

• 위 방법을 따른 이름의 의미가 불분명하다면 마지막 수단으로 접두어를 붙인다.
• ex) first~, last~

불필요한 맥락을 없애라

• 일반적으로 긴 이름이 짧은 이름보다 좋다고 했지만 그것은 의미가 분명한 경우이다.
• 이름에 불필요한 맥락을 추가하지 않도록 한다.
• ex) Gas Station Deluxe라는 애플리케이션을 만든다고 모든 클래스에 GSD를 붙이는 것은 바람직하지 않다.