DAY 2

<aside> 📕 오늘 읽은 범위

</aside>

• 2. 의미 있는 이름

<aside> 💡 책에서 기억하고 싶은 내용

</aside>

• 좋은 이름을 지으려면 시간이 걸리지만 좋은 이름으로 절약하는 시간이 훨씬 더 많다. (p. 22)
• 변수(혹은 함수나 클래스)의 존재 이유는? 수행 기능은? 사용 방법은? 따로 주석이 필요하다면 의도를 분명히 드러내지 못했다는 말이다. (p. 22)
• 프로그래머는 코드에 그릇된 단서를 남겨서는 안 된다. 그릇된 단서는 코드 의미를 흐린다. (p. 24)
• 유사한 개념은 유사한 표기법을 사용한다. 이것도 정보다. 일관성이 떨어지는 표기법은 그릇된 정보다. (p. 25)
• 이름이 달라야 한다면 의미도 달라져야 한다. (p. 26)
• customerInfo는 customer와, accountData는 account와, theMessage는 message와 구분이 안 된다. 읽는 사람이 차이를 알도록 이름을 지어라. (p. 27)
• 변수나 상수를 코드 여러 곳에서 사용한다면 검색하기 쉬운 이름이 바람직하다. (p. 28)
• 독자가 코드를 읽으면서 변수 이름을 자신이 아는 이름으로 변환해야 한다면 그 변수 이름은 바람직하지 못하다. (p. 31)
• 최악은 이미 a와 b를 사용하므로 c를 선택한다는 논리다. (p. 31)
• 이름이 다르면 독자는 당연히 클래스도 다르고 타입도 다르리라 생각한다. (p. 33)
• 일관성 있는 어휘는 코드를 사용할 프로그래머가 반갑게 여길 선물이다. (p. 33)
• 한 단어를 두 가지 목적으로 사용하지 마라. 다른 개념에 같은 단어를 사용한다면 그것은 말장난에 불과하다. (p. 34)
• 암기는 요즘 나오는 도구에게 맡기고, 우리는 문장이나 문단처럼 읽히는 코드 아니면 (정보를 표시하는 최선의 방법이 항상 문장만은 아니므로) 적어도 표나 자료 구조처럼 읽히는 코드를 짜는 데만 집중해야 마땅하다. (p. 38)