개발자 99% 커뮤니티에서 수다 떨어요!
오늘 읽은 범위: 2장.의미 있는 이름
- 이름을 잘 짓는 규칙
변수나 함수 그리고 클래스 이름은 존재 이유는? 수행 기능은? 사용 방법은?에 대한 질문에 답해야 한다.
널리 쓰이는 의미가 있는 단어를 다른 의미로 사용하지 말자.
컨테이너 유형을 이름에 넣지 말자. accountList -> accountGroup
l=1 O=0 같이 이름으로 그릇된 정보를 사용하지 말자.
이름이 달라야 한다면 의미도 달라져야 한다. 읽는 사람이 차이를 알도록 이름을 지어라.
연속적인 숫자(a1, a2, ..)를 덧붙인 이름은 아무런 정보도 제공하지 못한다.
의미가 불분명한 불용어: Product != ProductInfo, ProductData
getActiveAccount();
getActiveAcounts();
getActiveAcountInfo();
MAX_CLASSES_PER_STUDENT = 7
7은 검색이 어렵지만, MAX_CLASSES_PER_STUDENT는 검색 가능하다.
긴 이름이 짧은 이름보다 좋다. 검색하기 쉬운 이름이 상수보다 좋다. 다만 의미가 분명한 경우에 한한다. 이름에 불필요한 맥락을 추가하지 않도록 주의한다.,
버그를 검색으로 찾을 수 있어야 한다.
간단한 메서드에서 로컬 변수만 e, i, j 같은 한 문자를 사용한다.
이름을 잘 지어야 가독성 좋은 코드가 나온다는 것은 좋은 코드를 읽어본 사람이라면 전부 느끼는 바가 있을 것이다. 2장에서는 어떻게 이름을 잘 짓는지에 대한 규칙을 설명한다. 발음이 명확한 이름 짓기와 같이 당연한 내용은 빼고, 규칙으로써 염두에 두고 깊이 생각해봐야할 내용만 정리했다.
책에서 말한 규칙들을 원칙으로 세워 이름을 짓는다면 서로 충돌하는 부분도 있고, 오히려 더 많이 피곤해질 것 같다는 생각이 들었다. 결론적으로는 모든 과정을 겪어본 후에야 통찰력을 얻어 이름을 잘 지을 수 있는게 아닐까. 결국 리팩토링이 중요하다는 생각이 든다.
하지만 적어도 구현하는 동안 이름 짓기에 신중히 시간을 쓰는 습관을 들이는 것이 좋다고 생각한다. "일단 대충 짓고, 나중에 고치자"하면, 절대 고치지 않는다.
말장난을 사용하거나, 인코딩된 이름을 쓰는 코드를 최근에도 사용하는가? 책이 쓰인지 오래되어 예전 내용이 있는 것 같다.