@kimcoder

GitHubLinkedInFacebook

2장, 의미 있는 이름

2022.02.25

의도를 분명히 밝혀라

  • 좋은 이름을 지으려면 시간이 걸리지만 좋은 이름으로 절약하는 시간이 훨씬 많다.
  • 변수나 함수 그리고 클래스 이름은 다음과 같은 굵직한 질문에 모두 답해야 한다.
    • 존재 이유는?
    • 수행 기능은?
    • 사용 방법은?
  • 따로 주석이 필요하다면 의도를 분명히 드러내지 못했다는 말이다.
// bad
if (x[0] === 4) {
  list.add(x);
}

// good
if (cell[STATUS_VALUE] === FLAGGED) {
  flaggedCells.add(cell);
}

그릇된 정보를 피하라

  • 유사한 개념은 유사한 표기법을 사용한다. 이것도 정보다.
  • 일관성이 떨어지는 표기법은 그릇된 정보다.

여러 계정을 그룹으로 묶을 때, 실제 List가 아니라면 accountList라 명명하지 않는 것이 좋다.
프로그래머에게 List는 특수한 의미이기 때문에, accountGroup, Accounts 등으로 명명하자.

의미 있게 구분하라

  • 연속적인 숫자를 덧붙인 이름(a1, a2, ...)은 의도적인 이름과 정반대다.
    • 아무런 정보를 제공하지 못하는 이름이다.
    • 저자의 의도가 전혀 드러나지 않는다.
  • 불용어를 추가한 이름 역시 아무런 정보도 제공하지 못한다.
    • ProductData, ProductInfo
    • Info, Data는 a, an, the와 마찬가지로 의미가 불분명한 불용어다.
  • 읽는 사람이 차이를 알도록 이름을 지어라.
    • customerInfo는 customer와 accountData는 account와 구분이 안된다.

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

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

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

  • 이름 길이는 범위 크기에 비례해야 한다.
  • 변수나 상수를 코드 여러 곳에서 사용한다면 검색하기 쉬운 이름이 바람직하다.
  • WORK_DAYS_PER_WEEK는 찾기가 쉽지만, 숫자 5은 검색하기 어렵다.
// bad
for (int j=0; j<34; j++) {
  s += (t[j]*4)/5;
}

// good
const realDaysPerIdealDay = 4;
const WORK_DAYS_PER_WEEK = 5;

for (int j=0; j<NUMBER_OF_TASK; j++) {
  const realTaskDays = taskEstimate[j] * realDaysPerIdealDay;
  const realTaskWeeks = realTaskDays / WORK_DAYS_PER_WEEK;
  sum += (t[j]*4)/WORK_DAYS_PER_WEEK;
}

인코딩을 피하라

  • 문제 해결에 집중하는 개발자에게 인코딩은 불필요한 정신적 부담이다.

헝가리식 표기법

과거에는 컴파일러가 타입을 점검하지 않았으므로 프로그래머에게 타입을 기억할 단서가 필요했다. 하지만, 이제는 헝가리식 표기법이나 기타 인코딩 방식이 오히려 방해가 될 뿐이다.

멤버 변수 접두어

  • 클래스와 함수는 접두어가 필요없을 정도로 작아야 마땅하다.

이제는 멤버 변수에 m_이라는 접두어를 붙일 필요도 없다.
또한, 멤버 변수를 다른 색상으로 표시하거나 눈에 띄게 보여주는 IDE를 사용해야 마땅하다.

코드를 읽을수록 접두어는 관심 밖으로 밀려난다. 결국 접두어는 옛날에 작성한 구닥다리 코드라는 징표가 되버린다.

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

  • 옛날 코드에서 많이 사용하는 접두어 I는 주의를 흐트리고 과도한 정보를 제공한다.

인터페이스 클래스 이름과 구현 클래스 이름 중 하나를 인코딩해야 한다면 구현 클래스 이름을 택하겠다.
SharpFactoryImp나 CShapeFactory 가 IShapeFactory보다 좋다.

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

똑똑한 프로그래머와 전문가 프로그래머 사이에서 나타내는 차이점 하나만 들자면, 전문가 프로그래머는 명료함이 최고라는 사실을 이해한다. 전문가 프로그래머는 자신의 능력을 좋은 방향으로 사용해 남들이 이해하는 코드를 내놓는다.

클래스 이름

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

Customer, WikiPage, Account 등이 좋은 예이다. Manager, Processor, Data 등와 같은 단어는 피하고, 동사는 사용하지 않는다.

메서드 이름

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

postPayment, deletePage 등이 좋은 예다. 접근자, 변경자, 조건자는 앞에 get, set, is를 붙인다.
생성자 오버로드를 할 때는 정적 팩토리 메서드를 사용한다. 생성자 사용을 제한하려면 생성자를 private으로 선언한다.

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

  • 일관성 있는 어휘는 코드를 사용할 프로그래머가 반갑게 여길 선물이다.

DeviceManager와 ProtocolZController는 근본적으로 어떻게 다른가? 어쨰서 둘 다 Controller가 아닌가? 어째서 둘 다 Manager가 아닌가?
이름이 다르면 독자는 당연히 클래스도 다르고 타입도 다르리라 생각한다.

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

  • 코드를 읽을 사람도 프로그래머이다.
    • 그러므로 전산 용어, 알고리즘 이름, 패턴 이름, 수학 용어 등을 사용해도 괜찮다.
  • VISITOR 패턴에 친숙한 프로그래머는 AccountVisitor라는 이름을 금방 이해한다.

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

  • 우수한 프로그래머와 설계자라면 해법 영역과 문제 영역을 구분할 줄 알아야 한다.
  • 문제 영역 개념과 관련이 깊은 코드라면 문제 영역에서 이름을 가져와야 한다.

의미 있는 맥락을 추가하라

  • 클래스, 함수, 이름 공간에 넣어 맥락을 부여한다.
    • 모든 방법이 실패하면 마지막 수단으로 접두어를 붙인다.

예를 들어, firstName, lastName, city, state, zipcode라는 변수가 있다. 주소라는 사실은 금방 알아 챌 수 있을 것이다.
하지만 어느 메서드가 state라는 변수 하나만 사용한다면? state가 주소 일부라는 사실을 알아채기 쉽지 않다.
addr라는 접두어를 추가해 addrFirstName, addrState라 쓰면 맥락이 좀 더 분명해진다.
물론, Address라는 클래스를 생성하면 더 좋다.

불필요한 맥락을 없애라

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

accountAddress와 customerAddress는 Address 클래스 인스턴스로는 좋은 이름이나, 클래스 이름으로는 적합하지 않다.

마치면서

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

우리는 문장이나 문단처럼 읽히는 코드 아니면(정보를 표시하는 최선의 방법이 항상 문장만은 아니므로) 적어도 표나 자료 구조처럼 읽히는 코드를 짜는 데만 집중해야 마땅하다.

← Prev1장, 깨끗한 코드Next →3장, 함수