개발자 99% 커뮤니티에서 수다 떨어요!
2장 의미있는 이름
좋은 이름을 지으려면 시간이 걸리지만 좋은 이름으로 절약하는 시간이 훨씬 더 많다.(p.22)
따로 주석이 필요하다면 의도를 분명히 드러내지 못했다는 말이다.(p.22)
여러 계정을 그룹으로 묶을 때 실제 List가 아니라면 accountList라 명명하지 않는다(p.24)
의미가 있는 단어를 다른 의미로 사용해서는 안된다.(p.24): 특히 약어를 사용할 때 주의를 해야 한다. 읽는 사람을 고려해야 한다.
이름이 달라야 한다면 의미도 달라져야 한다(p.26): 연속된 숫자나 불용어(noise word)로 구분하면 정보제공이 되지 않기 때문에 저자의 의도를 알 수 없다. 의도를 알기 힘든 명명은 나쁘다.
불용어는 중복이다.(p.26): 여기서 말하는 불용어는 단순히 구분하기 위해 사용된 불필요한 단어다. 읽는 사람이 그 차이를 알기 어렵다.
한국인에게는 발음하기 쉬운과 함께 쉬운 단어를 사용하는 것도 중요할 듯 하다. 영어로 표기하는 이상 어려운 단어를 사용하면 결국 저자의 의도를 전달할 수 없을 것이기 때문이다.
코드 여러 곳에서 사용한다면 검색하기 쉬운 이름이 바람직하다.(p.28)
코딩상의 기능이나 타입 등에 대한 정보를 불필요하다면 굳이 명명하는데 포함하지 말라.
독자가 코드를 읽으면서 변수 이름을 자신이 아는 이름으로 변환해야 한다면 그 변수 이름은 바람직하지 못하다.(p.31)
클래스 이름과 객체이름은 명사나 명사구(p.32)
메서드 이름은 동사나 동사구(p.32)
의도를 분명하고 솔직하게 표현하라(p.33)
추상적인 개념 하나에 단어 하나를 선택해 이를 고수한다.(p.33): 같은 일을 하는 메서드는 같은 단어를 사용하고 다른 것은 확실히 다르게 표현해야 한다.
앞의 내용과 이어지는 내용으로 일관성을 지키려고 맥락이 다른 것에 동일한 이름을 붙여서는 안된다.
클래스, 함수, 이름공간에 넣어 맥락을 부여한다. 모든 방법이 실패하면 마지막 수단으로 접두어를 붙인다.(p.35): 클래스이름 등을 활용하여 맥락을 만들어준다.
일반적으로는 짧은 이름이 긴 이름보다 좋다. 단 의미가 분명한 경우에 한해서다. 이름에 불필요한 맥락을 추가하지 않도록 주의한다.(p.37)