Skip to content

chapter2-meaningful-names.md

Latest commit

 

History

History
128 lines (93 loc) · 5.1 KB

chapter2-meaningful-names.md

File metadata and controls

128 lines (93 loc) · 5.1 KB

2장 의미 있는 이름

❝코드는 남을 위해서 읽기 좋게 쓰는 것❞

❝이름은 짧을수록 좋지만, 짧은 대신 의미가 선명해야 한다. 길어도 되는 이유는, 코드보다 주석보다 이름이 더 중요하기 때문이다.❞

좋은 이름을 위한 원칙

원칙 1: 읽는 사람이 쉽게 이해할 수 있어야 한다

👉 "이름만 보고 용도를 유추할 수 있어야 한다."

  1. 의도를 분명히 밝혀라

    나쁜 예 좋은 예
    int d; int daysSinceCreation;
    • 변수명, 함수명, 클래스가 무엇을 하는지 정확하게 드러나야 한다.
      • 존재 이유
      • 수행 기능
      • 사용 방법

  2. 의미 있게 구분하라

    나쁜 예 좋은 예
    state addressState, userState
    • 의미가 모호한 단어는 맥락에 따라 명확히 구분해야 한다.
    • 이름이 달라야 한다면 의미도 달라야 한다.
      • 불용어를 사용한 이름은 아무런 정보도 제공하지 못한다.
        • ex) a1, a2, a3 … an
      • 읽는 사람이 알 수 있도록 구분되는 의미가 담겨야 한다.
        • accountData vs account

  3. 검색 가능한 이름을 써라

    나쁜 예 좋은 예
    int e; int employeeCount;
    5 MAX_CLASSES
    • 이름이 짧거나 모호한 변수, 상수는 코드 검색이 매우 어렵다.

원칙 2: 그릇된 정보를 피하라

// Set인데 이름은 List라 혼란을 유발
Set<Account> accountList = new HashSet<>();
  • 이름이 데이터의 구조나 역할과 다르면 오해를 일으킨다.
    • List라는 이름을 붙였는데 실제 자료형이 Set이라면 읽는 사람은 중복이 허용된다고 착각할 수 있다.
나쁜 예 좋은 예
userInfo, userData userRequest, userResponse 서로 다른 역할인데 이름만 보면 유사하게 느껴짐
dataManager, dataController cacheManager, httpController 실제 책임이 다르다면 이름도 구분 지어야 함
processHandler, processManager taskScheduler, taskRunner 추상적인 이름은 구체적인 역할로 바꾸자
  • 비슷하지만 다른 역할을 하는 이름에는 서로 확실히 다른 이름을 붙여야 한다.
나쁜 예 좋은 예
getUser(), fetchMember() getUser(), getMember() 동작은 동일한데 표현만 다르면 통일성 떨어짐
saveUser(), storeMember() saveUser(), saveMember() 동사는 하나로 통일해주는 게 좋음
calculateSum(), computeAverage() calculateSum(), calculateAverage() 같은 역할이면 접두사도 일치하는게 좋음
  • 반대로, 역할이나 용도가 비슷하다면 이름도 일관성 있게 유지해야 혼란을 줄일 수 있다.

❗이름에 잘못된 정보나 혼동을 줄 수 있는 표현은 피한다.

  • 헷갈리기 쉬운 철자는 피하는 것이 좋다.
    • l(소문자 L)과 1(숫자 1)
    • O(대문자 알파벳 O)와 0(숫자 0)
  • 잘못된 암시를 주는 단어도 혼동을 야기한다.
    • accountList → 실제는 Set<Account>
    • isAvailable → 실은 항상 false인 플래그
  • 복수형/단수형 이름의 오용도 주의
    • users가 User 하나만 담고 있는 경우 혼동을 준다.

원칙 3: 발음하기 쉬운 이름을 써라

나쁜 예 좋은 예
genymdhms generationTimestamp
  • 말로 설명하기 어려운 이름은 피한다.
  • 뉴비도 이해하기 쉽도록 만든다.

원칙 4: 인코딩을 피하라(불필요한 접두어를 제거)

나쁜 예 좋은 예
class CProductInfo class Product
strName, iCount name, count
  • 클래스명, 변수명에 헝가리안 표기법(C, M, S 등) 같은 접두어를 붙이면 오히려 가독성을 해친다.

원칙 5: 명사/동사 구분을 명확히 하라

구분 예시
클래스 (명사) User, Invoice, Product
함수 (동사) calculateTotal(), saveUser()
  • 역할에 맞게 자연스러운 문장처럼 읽히게 구성한다.
    • 클래스/변수는 명사, 함수는 동사로 이름을 짓는다.
  • 역할에 따라 이름 패턴을 정하면 자연스러운 코드 흐름을 만든다.
  • 생성자를 중복정의할 때는 정적 팩토리 메서드를 사용한다.

원칙 6: 한 개념에 한 단어를 사용하라

나쁜 예 좋은 예
fetchData(), retrieveUser() getData(), getUser() 같은 역할이면 동사를 통일해 혼란을 줄인다
  • 같은 동작에는 같은 표현을 반복해서 사용한다.
    • 예측 가능한 코드가 되고, 학습 비용이 줄어든다.
    • 주석을 보지 않아도 프로그래머가 올바른 메서드를 선택할 수 있다.