TIL #03 의미 있는 이름

오늘 TIL 3줄 요약

• 이름을 지을 때 의도가 분명하게 지어야 한다.
• 이름에 그릇된 정보가 들어가는 것을 피해야 한다.
• 가독성이 높은 코드를 짜는데에 집중해라.

---

TIL (Today I Learned) 날짜

• 2022. 04. 24

오늘 읽은 범위

• 2장 의미 있는 이름

---

책에서 기억하고 싶은 내용들

의도가 분명한 이름

변수, 함수, 클래스의 이름을 지을 때 다음의 질문에 모두 답해야 한다.

존재의 이유는? 수행 기능은? 사용 방법은?

별도의 주석이 필요하다면 의도를 분명히 드러내지 못한 것이다.

• int a와 int elaspedTimeInDays의 차이!

그릇된 정보를 주는 이름

그릇된 단서는 코드의 의미를 흐린다.

• 다른 의미로 해석 될 수 있는 단어 - hp (hypotenuse 약어? 유닉스 변종을 가리키는 이름?)
• 서로 흡사한 이름 사용 - XYZControllerForHandlingOfStrings, XYZControllerForStorageOfStrings
• 일관성이 떨어지는 표기법

의미 있게 구분하기

서로 다른 개념에 이름을 구분하기 위해 불용어(noise word)를 붙이거나, 연속된 숫자를 덧붙이는 방식은 제대로 된 정보를 제공하지 못한다.

• a1, a2, a3
• Product, ProductInfo, ProductData
• zork, theZork

읽는 사람이 차이를 알도록 이름을 지어야 한다.

발음하기 쉬운 이름

발음하기 쉬운 단어는 두뇌가 이해하기 쉽고 다른 사람들과 토론하기 쉽다.

• genymdhms와 generationTimestamp의 차이!

검색하기 쉬운 이름

문자 하나를 사용하는 이름과 상수는 텍스트 코드에서 쉽게 눈에 띄지 않고, 버그가 있을 때 검색으로 찾아내기 어렵다.

긴 이름이 짧은 이름보다 좋다.

s += (t[j]*4)/5;

int realTaskDays = taskEstimate[j] * realDaysPerIdalDay;
int realTaskWeeks = (realTaskDays / WORK_DAYS_PER_WEEK);
sum += realTaskWeeks;

인코딩 피하기

이름에 타입을 넣지 마라. 헝가리식 표기법이나 기타 인코딩 방식이 현대의 프로그래밍에서는 방해가 될 뿐이며 나중에 이름이나 타입을 바꾸기 어려워 지고 읽기도 어렵다.

PhoneNumber phoneString; // 타입이 바뀌어도 이름은 바뀌지 않는다

멤버 변수 접두어도 또한 불필요하다.

private String m_dsc;

인터페이스 클래스와 구현 클래스를 구분하기 위한 접두어도 붙이지 않는 편이 낫다. 읽는데 주의를 흐트리고 과도한 정보를 제공한다.

• IShapeFactory와 ShapeFactory

클래스와 메서드의 이름

클래스와 객체 이름은 명사나 명사구, 메서드의 이름은 동사나 동사구가 적합하다.

• 클래스, 객체 - Customer, WikiPage, Account
• 메서드 - getName, setName, FromRealNumber

그 외

• 기발한 이름은 피하기 - 의도를 분명히 하여 읽는 사람이 이해할 수 있어야 한다.
• 한 개념에 한 단어를 사용하기 - 똑같은 메서드를 클래스마다 다른 이름으로 사용하면 혼란스러워진다.
• 말장난 하지 않기 - 코드를 최대한 이해하기 쉽게 짜라.
• 의미 있는 맥락을 추가하고 불필요한 맥락을 제거하기
  FirstName → addrFirstName, GSDAccountAddress

결론

적어도 표나 자료 구조처럼 읽히는 코드, 가독성이 높은 코드를 짜는데 집중해라.

---

오늘 읽은 소감은?

• 클린 코드는 이름 짓기에서부터 매우 신중해야 함을 깨달았다.
• 좋지 않은 예시가 내가 했던 사례들과 유사함을 깨달았다...!
• 문장처럼 읽기 쉬운 코드, 이것을 명심해야겠다.

---

궁금한 내용

• 헝가리식 표기법

---

오늘 읽은 다른 사람의 TIL

• jinyoungp님의 TIL