[클린 코드] 2장. 의미 있는 이름

2022. 02. 20

 

 

📚 오늘 읽은 범위

2장. 의미 있는 이름

 

 

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

- 의도를 분명히 밝혀라 (p.22)

- 프로그래머는 코드에 그릇된 단서를 남겨서는 안 된다. 그릇된 단서는 코드 의미를 흐린다. 나름대로 널리 쓰이는 의미가 있는 단어를 다른 의미로 사용해도 안 된다. (p.24)

- 서로 흡사한 이름을 사용하지 않도록 주의한다. (p.24)

- 유사한 개념은 유사한 표기법을 사용한다. 이것도 정보다. 일관성이 떨어지는 표기법은 그릇된 정보다. (p.25)

- 컴파일러를 통과할지라도 연속된 숫자를 덧붙이거나 불용어를 추가하는 방식은 적절하지 못하다. 이름이 달라야 한다면 의미도 달라져야 한다. (p.26)

- 읽는 사람이 차이를 알도록 이름을 지어라. (p.27)

- 발음하기 쉬운 이름을 사용하라. (p.27)

- 검색하기 쉬운 이름을 사용하라. (p.28)

- 인코딩을 피하라. (p.29)

- 전문가 프로그래머는 명료함이 최고라는 사실을 이해한다. 전문가 프로그래머는 자신의 능력을 좋은 방향으로 사용해 남들이 이해하는 코드를 내놓는다. (p.31-32)

- 클래스 이름과 객체 이름은 명사나 명사구가 적합하다. (p.32)

- 메서드 이름은 동사나 동사구가 적합하다. (p.32)

- 생성자를 중복정의할 때는 정적 팩토리 메서드를 사용한다. 메서드는 인수를 설명하는 이름을 사용한다. (p.32)

- 재미난 이름보다 명료한 이름을 선택하라. (p.32)

- 한 개념에 한 단어를 사용하라. (p.33)

- 한 단어를 두 가지 목적으로 사용하지 마라. (p.34)

- 프로그래머는 코드를 최대한 이해하기 쉽게 짜야 한다. 집중적인 탐구가 필요한 코드가 아니라 대충 훑어봐도 이해할 코드 작성이 목표다. (p.34)

- 모든 이름을 문제 영역에서 가져오는 정책은 현명하지 못하다. (p.34)

- 우수한 프로그래머와 설계자라면 해법 영역과 문제 영역을 구분할 줄 알아야 한다. 문제 영역 개념과 관련이 깊은 코드라면 문제 영역에서 이름을 가져와야 한다. (p.35)

- 모든 방법이 실패하면 마지막 수단으로 접두어를 붙인다. (p.35)

- 일반적으로는 짧은 이름이 긴 이름보다 좋다. 단, 의미가 분명한 경우에 한해서다. 이름에 불필요한 맥락을 추가하지 않도록 주의한다. (p.37)

 

 

🙌 오늘 읽은 소감

- 코드를 작성할 때 변수명, 메서드명, 클래스명 다 의미 있는 이름을 사용하려고 생각하면서 지었었는데 그동안 잘해왔구나 생각하게 되었다. 내가 여태 해온 것들이 그래도 의미가 없진 않았구나 하는 생각. 하지만 부족한 부분들도 있어서 앞으로 코드 작성할 때 오늘 읽었던 부분을 조금 더 생각하면서 작성해야겠다.

- 역시 개발자는 혼자 하는 직업이 아니라 협업이 중요하구나 다시 한 번 깨닫는 계기가 되었다. 협업 경험이 부족한 나로써는 이런 부분에서 많은 것을 느끼지 못해서 아쉬웠다. 이것 저것 많이 경험해봐야지.