2장 의미있는 이름
- 의도를 분명히 밝혀라
- 의도가 드러나는 이름을 사용하면 코드 이해와 변경이 쉬워진다.
- 문제는 코드의 단순성이 아니라 코드의 함축성이다.
- 그릇된 정보를 피하라
- 코드에 그릇된 단서를 남겨서는 안 된다.
- List라는 단어는 특수한 의미다.
- 일관성이 떨어지는 표기법은 그릇된 정보다.
- 의미 있게 구분하라
- 연속된 숫자(a1, a2…)를 덧붙이거나 불용어(ProductInfo, ProductData)를 추가하는 방식은 적절하지 못하다.
- 읽는 사람이 차이를 알도록 이름을 지어라.
- 발음하기 위운 이름을 사용하라.
- 우리 두뇌에서 상당 부분은 단어라는 개념만 전적으로 처리한다.
- 검색하기 쉬운 이름을 사용하라.
- 문자 하나를 사용하는 이름과 상수는 텍스트 코드에서 윕게 눈에 띄지 않는 다는 문제점이 있다.
- 긴 이름이 짧은 이름보다 좋다. 검색하기 쉬운 이름이 상수보다 좋다.
- 이름 길이는 범위 크기에 비레해야 한다. 여러 곳에서 사용한다면 검색하기 쉬운 이름이 바람직하다.
- 인코딩을 피하라.
- 이제는 헝가리식 표기법이나 기타 인코딩 방식이 오히려 방해가 될 뿐이다.
- 인터페이스 클래스이름과 구현 클래스 이름 중 하나를 인코딩해야 한다면 구현클래스 이름을 인코딩한다.
- 자신의 기억력을 자랑하지 마라.
- 독자가 코드를 읽으면서 변수 이름을 자신이 아는 이름으로 변환해야 한다면 그 변수 이름은 바람직하지 못하다.
- 클래스 이름과 객체 이름은 명사나 명사구가 적합하다.
- 메서드 이름은 동사나 동사구가 적합하다.
- 생성자를 중복정의 할 때는 정적 팩토리 메서드를 사용한다.
- 기발한 이름은 피하라.
- 한 개념에 한 단어를 사용하라.
- 추상적인 개념 하나에 단어 하나를 선택해 이를 고수한다.
- 메서드 이름은 독자적이고 일관적이어야 한다.
- 말장난을 하지 마라
- 한 단어를 두 가지 목적으로 사용하지 마라. (add가 기존 값 두개를 더하는 게 있고 새로 작성하는 게 List에 값을 하나 더하는 거라면 insert나 append라는 이름을 사용한다.)
- 해법 영역에서 가져온 이름을 사용하라.
- 기술 개념에는 기술 이름이 가장 적합한 선택이다.
- 적절한 '프로그래머 용어'가 없다면 문제 영역에서 이름을 가져온다.
- 의미 있는 맥락을 추가하라
- 모든 방법이 실패하면 마지막 수단으로 접두러를 붙인다.
- 어느 메서드가 state라는 변수 하나만 사용한다면 변수 state가 주속 일부라는 사실을 알 수 있을 까?
- 물론 Addres라는 클래스를 생성하면 더 좋다.
- 불필요한 맥락을 없애라.
- 모든 클래스 이름을 GSD(애플리케이션 특유의 접두어)로 시작하겠다는 생각을 전혀 바람직하지 못하다.
- 일반적으로는 짧은 이름이 긴 이름보다 좋다. 단 의미가 분명한 경우에 한해서다.
'책정리 > 방법론' 카테고리의 다른 글
클린코드 - 6장 객체와 자료구조 (0) | 2017.01.12 |
---|---|
클린코드 - 5장 형식 맞추기 (0) | 2017.01.11 |
클린코드 - 4장 주석 (0) | 2017.01.10 |
클린코드 - 3장 함수 (0) | 2017.01.10 |
댓글