[Clean Code(클린 코드)] 2장 의미있는 이름

본 게시글은 <Clean Code>를 학습한 내용을 정리한 글입니다. (문제시 삭제하겠습니다.)

Clean Code(클린 코드) - 교보문고

 

 

의도를 분명히 밝혀라

• 좋은 이름을 지으려면 시간이 걸리지만 좋은 이름으로 절약하는 시간이 훨씬 더 많다.
• 변수나 함수 그리고 클래스 이름은 다음과 같은 굵직한 질문에 모두 답해야 한다.
  • 변수(혹은 함수나 클래스)의 존재 이유는?
  • 수행 기능은?
  • 사용 방법은?
• 따로 주석이 필요하다면 의도를 분명히 드러내지 못했다는 말이다.
• 의도가 드러나는 이름을 사용하면 코드 이해와 변경이 쉬워진다.

그릇된 정보를 피하라

• 그릇된 단서는 코드 의미를 흐린다. 실제 List가 아니라면 xxxList라 명명하지 않는다.
• 유사한 개념은 유사한 표기법을 사용한다. 일관성이 떨어지는 표기법은 그릇된 정보다.
• 이름으로 그릇된 정보를 제공하는 진짜 끔찍한 예가 소문자 L이나 대문자 O 변수다. 소문자 L은 숫자 1처럼 보이고 대문자 O는 숫자 0cjfja qhdlsek.

의미있게 구분하라

• 컴파일러나 인터프리터만 통과하려는 생각으로 코드를 구현하는 프로그래머는 스스로 문제를 일으킨다.
• 컴파일러를 통과할지라도 연속된 숫자를 덧붙이거나 불용어(noise word)를 추가하는 방식은 적절하지 못한다. 이름이 달라야 한다면 의미도 달라져야 한다.
• 불용어를 추가한 이름 역시 아무런 정보도 제공하지 못한다.
  • Product라는 클래스가 있다고 가정
  • 다른 클래스를 ProductInfo 혹은 ProductData라 부른 다면 개념을 구분하지 않은 채 이름만 달리한 경우다.
  • Info나 Data는 a, an, the와 마찬가지로 의미가 불분명한 불용어다.
• 불용어는 중복이다.
  • NameString이 Name보다 뭐가 나은가?
  • Customor라는 클래스와 CustomerObject라는 클래스를 발견했다면 차이를 알겠는가? 고객 급여 이력을 찾으려면 어느 클래스를 뒤져야 빠를까?
  • 읽는 사람이 차이를 알도록 이름을 지어라.

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

• 발음하기 어려운 이름은 토론하기도 어렵다. 발음하기 쉬운 이름은 중요하다. 프로그래밍은 사회 활동이기 때문이다.

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

• 문자 하나를 사용하는 이름과 상수는 텍스트 코드에서 쉽게 눈에 띄지 않는다는 문제점이 있다.
  • MAX_CLASSES_PER_STUDENT는 grep으로 찾기가 쉽지만, 숫자 7은 은근히 까다롭다.
  • 7이 들어가는 파일 이름이나 수식이 모두 검색되기 때문이다.
  • 검색은 되었지만 7을 사용한 의도가 다른 경우도 있다.
• 개인적으로는 간단한 메서드에서 로컬 변수만 한 문자를 사용한다.
• 이름 길이는 범위 크기에 비례해야 한다. 변수나 상수를 코드 여러 곳에서 사용한다면 검색하기 쉬운 이름이 바람직하다.

인코딩을 피하라

• 굳이 부담을 더하지 않아도 이름에 인코딩할 정보는 아주 많다.
• 유형이나 범위 정보까지 인코딩에 넣으면 그만큼 이름을 해독하기 어려워진다.
• 헝가리식 표기법 → 객체는 강한 타입이며 IDE는 코드를 컴파일하지 않고도 타입 오류를 감지할 정도로 발전했다. 따라서 이제는 헝가리식 표기법이나 기타 인코딩 방식이 오히려 방해가 될 뿐이다.
• 멤버 변수 접두어 → 클래스와 함수는 접두어가 필요없을 정도로 작아야 마땅하다. 또한 멤버 변수를 다른 색상으로 표시하거나 눈에 띄게 보여주는 IDE를 사용해야 마땅하다.
• 인터페이스 클래스와 구현 클래스 → 때로는 인코딩이 필요한 경우. 인터페이스 클래스 이름과 구현 클래스 이름 중 하나를 인코딩해야 한다면 구현 클래스 이름을 택하겠다.

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

• 전문가 프로그래머는 명료함이 최고라는 사실을 이해한다. 프로그래는 자신의 능력을 좋은 방향으로 사용해 남들이 이해하는 코드를 내놓는다.

클래스 이름

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

메서드 이름

• 메서드 이름은 동사나 동사구가 적합하다.
• 생성자를 overload할 때는 정적 팩토리 메서드를 사용한다.
  • 정적 팩토리 메서드 : 객체 생성의 역할을 하는 클래스(https://tecoble.techcourse.co.kr/post/2020-05-26-static-factory-method/)
  • 생성자 대신 정적 팩토리 메서드를 사용하면 메서드 이름에 객체의 생성 목적을 담아낼 수 있다.
  • 정적 팩터리 메서드와 캐싱구조를 함께 사용하면 매번 새로운 객체를 생성할 필요가 없어진다.
  • 상속을 사용할 때 하위 자료형 객체를 반환할 수 있다. Basic, Intermediate, Advanced 클래스가 Level라는 상위 타입을 상속받고 있는 구조를 생각해보자. 시험 점수에 따라 결정되는하위 등급 타입을 반환가능하다.

기발한 이름은 피하라

• 재미난 이름보다 명료한 이름을 선택하라.
• 의도를 분명하고 솔직하게 표현하라.

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

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

말장난을 하지 마라

• 한 단어를 두 가지 목적으로 사용하지 마라. 다른 개념에 같은 단어를 사용한다면 그것은 말장난에 불과하다.

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

• 코드를 읽을 사람도 프로그래머라는 사실을 명심한다. 그러므로 전산 용어, 알고리즘 이름, 패턴 이름, 수학 용어 등을 사용해도 괜찮다.
• 기술 개념에는 기술 이름이 가장 적합한 선택이다.

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

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

의미있는 맥락을 추가하라

• 스스로 의미가 분명한 이름이 없지 않다. 하지만 대다수 이름은 그렇지 못하다. 그래서 클래스, 함수, 이름 공간에 넣어 맥락을 부여한다. 모든 방법이 실패하면 마지막 수단으로 접두어를 붙인다.
• 예를 들어, firstName, lastName, street, houseNumber, city, state, zipcode라는 변수가 있다.
  • 변수를 훑어보면 주소라는 사실을 금방 알아챈다. 하지만 어느 메서드가 state라는 변수 하나만 사용한다면? 변수 state가 주소 일부라는 사실을 금방 알아챌까?
  • addr라는 접두어를 추가해 addrFirstName, addrLastName, addrState라 쓰면 맥락이 좀 더 분명해진다. 변수가 좀 더 큰 구조에 속한다는 사실이 적어도 독자에게는 분명해진다.
  • 물론 Address라는 클래스를 생성하면 더 좋다.

불필요한 맥락을 없애라

• 일반적으로는 짧은 이름이 긴 이름보다 좋다. 단, 의미가 분명한 경우에 한해서다. 이름에 불필요한 맥략을 추가하지 않도록 주의한다.