1 주차
일 | Assignment #03
2장. 의미 있는 이름
📘 책에서 기억하고 싶은 내용
- 좋은 이름을 지으려면 시간이 걸리지만 좋은 이름으로 절약하는 시간이 훨씬 더 많다. (p.22)
- 그릇된 정보를 피하라 (p.24)
- 코드에 잘못된 정보를 줄 수 있는 부분은 코드의 의미를 흐리기 때문에 최소화해야 한다.
- 널리 쓰이는 의미가 있는 단어를 다른 의미로 사용하면 안 된다.
- 데이터를 그룹으로 묶을 때 컨테이너가 List인 경우에도 컨테이너 유형을 변수명에 넣지 않는 편이 바람직하다.
- 서로 흡사한 이름을 사용하지 않도록 주의한다.
- 의미 있게 구분하라 (p.25)
- 연속된 숫자를 덧붙이거나 불용어(Noise Word)를 추가하는 방식은 아무런 정보를 제공해주지 못한다.
- 인코딩을 피하라 (p.29)
- 컴파일러와 IDE의 발전으로 이제는 헝가리식 표기법이나 기타 인코딩 방식이 오히려 타입 변경이나 이해에 방해가 된다. (p.30)
- 자신의 기억력을 자랑하지 마라 (p.31)
- 다른 사람이 코드를 읽으며 변수 이름을 자신이 아는 이름으로 변환해야 한다면 그 변수 이름은 바람직하지 못하다.
- 문자 하나만 사용하는 변수 이름은 문제가 있다.
클래스명, 객체명 : 명사나 명사구가 적합하며, 동사는 사용하지 않는다. (Data, Info, Processor과 같이 범용적으로 사용되는 단어는 가급적 피해야 함) (p.32)
메서드명 : 동사나 동사구가 적합하며, 접근자/변경자/조건자는 JavaBeans 표준에 따라 값 앞에 get, set, is를 붙인다. (p.32)
- 생성자를 중복 정의할 때는 정적 패토리 메서드를 사용한다.
- 한 개념에 한 단어를 사용하라, 하지만 일관성을 고려해 맥락이 다른 경우에도 같은 단어를 사용하면 안 된다. (p.33~34)
- 일반적으로 의미가 분명한 경우에 한해 짧은 이름이 긴 이름보다 좋지만, 이름에 불필요한 맥락을 추가하지 않도록 한다. (p.37)
🤔 소감 및 생각
- 예전에 오래된 레거시 시스템의 코드를 유지보수 해야 할 때가 있었는데, 가독성이 어려운(마음에 들지 않는) 명명규칙도 지켜야 할 관례라고 생각하여 기존 관례를 유지하면서 구현했었다. 그러다 적어도 내가 건드린 부분이라도 조금씩 고쳐 나가보자는 생각이 들어 이후에는 그렇게 구현했었는데 그 생각이 옳았다는 것을 인정받은 느낌이었다.
- 변수 등 여러 이름을 쉽게 정하지 못했던 적이 많았는데 앞으로도 다른 사람들이 읽고 이해하기 좋은 이름을 정할 수 있도록 노력해야겠다.
🔍 새롭게 알게 된 내용
