Chapter 2 - Naming Convention

in Booknotes / Clean Code

좋은 이름을 지으려면 시간이 걸리나 절약하는 시간이 훨씬 더 많다

의도를 분명히 밝혀라

  • 이름은 다음의 질문에 모두 답해야 한다. 따로 주석이 필요하다는 것은 잘 짓지 못했다는 것이다
    1. 존재 이유
    2. 수행 기능
    3. 사용 방법

그릇된 정보를 피하라

  • 실제 List가 아니라면 accountList를 사용 X 실제 컨테이너가 List라도 안 쓰는게 좋다
  • 약어 지양

의미 있게 구분하라

  • 불용어 (noise word) 금지
  • 불용어를 추가한 이름도 금지
    • ex: Product에 Info, Data 붙여 ProductInfo, ProductList 붙이기 NameString, moneyAmount, theMessage...

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

  • 프로그래밍은 사회활동이다
    • ex: genymdhms generate date, year, month, day, hour, min, sec 발음: 젠 와이 엠디에이취엠에스.. \(\rightarrow\) generationTimestamp로 변경

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

  • 모든 숫자를 상수처리하는 이유 중 하나이다 ex: 7을 찾으면 엄청난 양의 결과가 나올 것..
  • ex: 3/7 보다는 SENT_MAILS / TOTAL_MAILS가 더 쉬움
  • 이름 길이는 범위 크기에 비례 : 많이 사용될수록 쉬운 이름이 바람직

인코딩을 피하라

  • 유형이나 범위정보까지 넣으면 이름 해독이 어려워짐

헝가리식 표기법

  • (Hungarian Notation): 이제는 거의 사라진, 변수명 앞에 데이터타입을 붙인 표기법 m_lpsName
  • 옛날: 컴파일러가 타입 점검 X, 프로그래머에게 타입을 기억할 단서 필요
  • 지금: 더 많은 타입, 컴파일러가 기억하고 강제하며 클래스/함수 점차 줄어듬 \(\rightarrow\) 변수 선언 위치와 사용 위치 가까움

  • JAVA: 객체 = strongly-typed, IDE는 컴파일 안하고도 타입 오류 감지 가능

  • PhoneNumber phoneString 이러한 경우에 타입을 바꿔도 이름은 안바꿔도 된다 \(\rightarrow\) 유지보수 EZ

멤버 변수 접두어

  • now obsolete
  • 멤버 변수임을 명시하기 위해 m_ 접두어 붙여 사용했었다.

인터페이스 클래스와 구현 클래스

  • ShapeFactory에 대해 Interface와 Class의 이름을 정의해야 한다면 차라리 구현 클래스 이름에 인코딩을 하겠다 -저자

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

  • 코드를 읽으며 독자의 아는 이름으로 변환해야 한다면 그 변수이름은 바람직하지 못함

  • 루프 변수 ( i , ` j , k ) 뺴고 한문자 금지 (특히 l `)

  • 똑똑한 프로그래머: 변수명 기억을 잘함
  • 전문가 프로그래머: 명료함이 1순위인걸 인지하고 있음

클래스/객체 이름

  • 명사구가 적합, 동사 최대한 사용X
  • GOOD: Customer, WikiPage, Account, AddressParser
  • BAD: Manager, Processor, Data, Info

메서드 이름

  • 동사/동사구 적합
  • GOOD: postPayment, deletePage, save
  • JAVA는 javabean 표준에 따라 앞에 붙이기
    1. 접근자 (Accessor) : get
    2. 변경자 (Mutator) : set
    3. 조건자 (Predicate) : is

기발한 이름은 피하라

  • 유며, 재미있는 이름 금지 (단기적으로만 기억함)
  • 특히 특정 문화에서만 통용되는 경우도 피할것

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

  • 일관성 있는 어휘
  • 추상적인 개념하나에 단어 하나만 사용
  • 가져오는 메서드들에 fetch, retrieve, get 다 사용하면 헷갈림
  • controller, manager, driver 도 마찬가지

말장난을 하지 마라

  • 한단어를 두 가지 목적으로 사용 금지
  • 리스트에 값을 추가할때, insert, append가 아닌 add를 사용하는 경우 \(\Rightarrow\) 말장난

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

  • Domain Knowledge가 유독 드러나는 영역인만큼, 적극 활용하기 (어차피 읽는 사람도 프로그래머)
  • “기술 개념에는 기술 이름이 가장 적합한 선택이다”

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

  • 적절한 ‘프로그래밍 용어’가 없으면 문제 영역에서 이름을 가져오기
  • \(\Rightarrow\) 유지보수 시 분야 전문가에게 물어봐서 파악 가능함

의미 있는 맥락을 추가하라

  • firstName, lastName, street, houseNumber, city, state, zipcode \(\rightarrow\) 주소임을 쉽게 파악 가능
    • 하지만 state 혼자 쓰이면 혼란
  • \(\Rightarrow\) addrFirstName, addrLastName, addrState 처럼 사용

불필요한 맥락을 없애라

  • 일반적으로 짧은 이름이 긴 이름보다 좋지만 의미가 분명한 경우에 한해서만이다.
  • 모든 클래스 앞에 같은 단어를 붙이면 IDE가 자동추천해 주는 리스트가 의미 없어질 것

개인회고

당장 어제 쓴 코드부터 뜯어고치고 싶다. 특히나 MemberList, FeeAmount 같은걸 많이 썼는데, 작가님이 내 코드를 리뷰해주신 느낌이었다. 변수명을 짧게 (a, b, n, m) 하는 습관이 최근에야 없어졌는데, 백준같이 짧고 유지보수 가능성이 아예 없는 코드를 오랫동안 짜다보니 실제 프로젝트에서도 나만 사용할 코드라는 생각에 이렇게 짰던 적이 있었다. 간단히 알고 넘기는 것이 아닌, 책으로 읽어보니 기억에 고스란히 남아 앞으로 코드를 작성할떄 훨씬 염두에 두고 코딩할 것 같다.