[클린 코드] Ch.2 - 의미 있는 이름
해당 서적을 참고하여 개인 공부용으로 정리한 글입니다.
명명 규칙(Naming Rule)
변수부터 파일명, 디렉토리명 까지 이름은 다양한 곳에 붙여진다.
따라서, 이름을 잘 짓기위한 몇 가지 규칙을 정한다.
의도를 분명히 밝힐 것
변수/함수/클래스 존재 이유나 수행 기능, 사용 방법 등을 설명하기 위해 따로 주석이 필요하다면 의도를 분명히 드러내지 못했다는 것이다.
간단한 코드라도 함축성이 부족하다면 무엇을 의미하는지 해독해야 한다. (아무리 정상 작동하는 코드라도)
정보 제공 방법은 다양하다.
- 타입/클래스를 잘 활용할 것 (ex. int[] -> Cell)
- 상수는 static final로 설정해 무엇을 의미하는지 표현할 것
그릇된 정보를 피할 것
당연한 얘기지만 생각치 못하게 그릇된 정보를 제공할 수도 있다.
- 널리 쓰이는 의미가 있는 단어를 다른 의미로 사용할 경우
- 그룹으로 묶을 때, 실제 List가 아닌데 suffix에 List를 붙이는 경우 (ex. accountList -> accounts로 변경)
- 서로 흡사한 이름을 사용하는 경우
- l(소문자 L)과 I(대문자 i) 처럼 폰트에 따라 같아 보이는 경우
의미있게 구분할 것
- 연속된 숫자같은 불용어(noise word)를 추가하지 않는다. (ex. a1, a2 || productInfo, productData)
- 이름이 달라야 한다면 의미도 달라져야 한다.
- 불용어는 중복이다.
- 읽는 사람이 차이를 알도록 이름을 짓는다.
발음하기 쉬운 이름을 사용할 것
이름은 단어다. 단어는 발음할 수 있다. 발음하기 쉬운 이름은 소통에 용이하다.
검색하기 쉬운 이름을 사용할 것
문자 하나를 사용하는 이름과 상수는 쉽게 눈에 띄지 않는다.
grep이나 Ctrl + F로 검색해도 포함되는 위치가 너무 많을 수 있다.
따라서 긴 이름이 짧은 이름보다 검색하기 좋다.
일반적으로, 이름 길이는 범위 크기에 비례해야 한다. (사용되는 곳이 많을 수록 긴 코드)
인코딩을 피할 것
이름에 유형이나 범위까지 넣으면 해독하기 어려워지고, 발음하기도 어렵고, 오타가 생기기도 쉽다.
과거에 사용된 헝가리안 표기법은 이제는 쓸 필요가 없으며, 멤버 변수 접두어 역시 마찬가지이다.
때로는 인코딩이 필요한 경우도 있다.
인터페이스와 구현 클래스가 있을 경우 구분하기 위해 접두어나 접미어가 있으면 좋다.
예를 들어, 도형을 생성하는 인터페이스 클래스와 구현 클래스가 있을 때,
IShapeFactory와 ShapeFactory로 지어야할까?
클린 코드 작가는 다루고 있는 클래스가 인터페이스라는 사실을 알리고 싶지 않아서
인터페이스는 ShapeFactory로 두고, 구현 클래스를 인코딩 해 ShapeFactoryImp 형태로 명명한다.
명료하게 표현할 것
독자가 코드를 읽으면서 변수명을 본인이 아는 이름으로 변환해야 한다면 바람직하지 못한 것이다.
변환하거나 외우지 않아도 누가봐도 이해할 수 있는 코드를 작성해야 한다.
클래스 이름
클래스/객체 이름은 명사나 명사구가 적합하다.
단, Manager, Processor, Data, Info 등과 같이 애매모호한 단어는 피하고, 동사는 사용하지 않는다.
메서드 이름
동사나 동사구가 적합하다.
접근자(Accessor), 변경자(Mutator), 조건자(Predicate)는 javabean 표준에 따라 get, set, is를 붙인다.
생성자를 오버로드할 때는 정적 팩토리 메서드(빌더 패턴)을 사용한다.
기발한 이름은 피할 것
- 재미난 이름보다 명료한 이름을 선택할 것
- 특정 문화에서만 사용하는 농담은 피할 것
한 개념에 한 단어를 사용할 것
- 추상적인 개념 하나에 단어 하나를 선택해 이를 고수할 것
- fetch, retrieve, get 처럼 클래스마다 다르게 부르면 혼란스럽다.
- 일관성 있는 어휘 사용
한 단어를 두 가지 목적으로 사용하지 말 것
기존 값 두 개를 더해서 새로운 값으로 만드는 add 메서드가 있다.
새로 작성하는 메서드는 집합에 요소 하나를 추가한다.
이 메서드를 add라 부르면 안된다는 것이다.
일관성을 지키려면 insert나 apped라는 이름이 적당하다.
독자도 프로그래머임을 명심할 것
모든 이름을 도메인 영역에서 가져올 필요는 없다.
알고리즘 이름, 패턴 이름, 수학 용어 등을 사용해도 무방하다.
적절한 프로그래머 용어가 없다면, 도메인 영역에서 이름을 가져온다.
도메인 영역 개념과 관련이 깊은 코드라면 도메인 영역에서 가져온다.
의미있는 맥락을 추가할 것
의미를 분명하게 하기위해 클래스, 함수, 이름 공간에 넣어 맥락을 부여한다.
모든 방법이 실패하면 마지막 수단으로 접두어를 붙인다.
맥락을 개선하면 함수를 쪼개기가 쉬워지므로 알고리즘도 좀 더 명확해진다.
불필요한 맥락을 없앨 것
의미가 분명한 경우에 한해 짧은 이름이 긴 이름보다 좋다.
의미가 있다고 해서 접두어나 접미어를 과하게 붙일 필요가 없다.
결론
- 좋은 이름은 코드를 읽기 쉽게 한다.
- 좋은 이름을 선택하는 것은 쉬운 일이 아니다.
- 다른 사람이 반대할까 두렵더라도 코드 가독성을 개선하는 노력을 중단해서는 안된다.