2. 의미있는 이름

의도를 분명하게 밝혀라

   - 이름을 대강 지어두고 주석으로 설명하는 것보다는 어떤 의도를 가지고 변수를 선언했는지가 이름에 드러나도록

   - 코드의 "함축성": 코드의 맥락이 보이도록 (읽는 사람에게 정보 전달)

 

그릇된 정보를 피하라

   - 정확한 정보 전달이 가능한 이름 선언

   - 흡사한 이름 사용하지 않기 (ex. XYXControllerForEfficientHandlingOfStrings, XYZControllerForEfficientStorageOfStrings)

 

의미 있게 구분하라

   - a1, a2, a3 같은 이름 말고 의도가 드러나는 이름을 사용

   - 불용어 줄이기 (ex. NameString > Name, CustomerObject > Customer)

 

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

 

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

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

   - 검색하기 쉬운 이름이 상수보다 좋다 (매직 넘버?)

 

인코딩을 피하라

   - 쓸데없이 접두어를 붙이지 않아도 맥락을 이해할 수 있는 것이 좋다

 

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

   - i, j, k 같은 변수를 반복문 이외의 구문에서 제거하자

 

클래스 이름

   - 명사 or 명사구

 

메서드 이름

   - 동사 or 동사구

 

기발한 이름은 피하라

   - 명료한 이름 사용하기

 

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

   - 뭔가를 가져오는 것들을 만들 때 fetch, retrieve, get을 섞어 쓰지 말고 하나만 쓰기

   - contoller, manager, driver 중에 하나만 쓰기

 

말장난을 하지 마라

   - 하나의 개념에 하나의 단어 사용 (ex. add가 기존 값 두 개를 더하거나 이어서 새로운 값을 낸다면 집합에 값 하나를 추가하는 건 add가 아닌 append나 insert를 사용하도록 하자)

 

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

   - 이미 프로그래밍 영역에서 사용중인 이름이 있다면 사용

 

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

 

의미있는 맥락을 추가하라

   - 맥락을 유추하는 게 아닌 확실히 이해하도록 추가 (ex. state, zipCode > addrState, addrZipCode)

 

불필요한 맥락을 없애라

   - 의미가 분명한 경우, 짧은 이름이 긴 이름보다 좋다 (간결할수록 눈에 잘 들어와서 파악이 잘 됨)

---

개발할 때 제일 어려운 것, 바로 네이밍... 길면 긴 대로 불편하고 짧으면 짧은 대로 불편해서 그 적당한 지점을 찾기가 참 어렵다.

그럼에도 이름을 잘 지어야 하는 건, 보통 일할 때 코드를 혼자 보는 것이 아니니까..! (물론 혼자 보더라도 의미 있는 이름으로 지어야 미래의 내가 고생하지 않는다)