이름을 잘짓는 규칙을 몇가지 소개하려 한다.
해당 포스팅 내용은 책 'Clean Code - Robert C. Martin' 출처로 합니다.
1. 의도를 분명히 밝혀라
좋은 이름을 지으려면 시간이 걸리지만 그로 인해 절약하는 시간이 훨씬 더 많기 때문에 좋은 이름을 짓도록 노력해야 한다.
이때, 변수나 함수 클래스 이름을 지을 때 아래와 같은 질문에 답을 할 수 있어야 한다.
▶ 변수(혹은 함수나 클래스)의 존재 이유가 무엇인가?
▶ 수행기능은 무엇인가?
▶ 사용방법은 어떻게 되는가?
만약 따로 많은 주석이 필요하다면 의도를 분명히 드러내지 못한 것이다.
-> 코드의 단순성보다 중요한 것은 코드의 함축성이다.
2. 그릇된 정보를 피하라
나름대로 널리 쓰이는 의미가 있는 단어를 다른 의미로 사용하면 안 된다.
예를 들어,
- hp, aix, sco는 유닉스 플랫폼이나 유닉스 변종을 가리키는 의미이다. 만약 직각삼각형의 빗변(hypotenuse)을 구현할 때 hp라는 변수 를 사용하면 독자에게 그릇된 정보를 제공할 수 있다.
- 여러 계정을 그룹으로 묶을 때, 실제 List가 아니라면, accountList라 명명하지 않는다. 프로그래머에게 List라는 단어는 특수한 의미이다.
서로 흡사한 이름을 사용하지 않도록 주의해야 한다.
유사한 개념은 유사한 표기법을 사용한다. 표기된 이름은 일종의 정보이기 때문에 일관성이 떨어지는 표기법은 그릇된 정보다.
3. 의미있게 구분하라
연속된 숫자를 덧붙이거나 불용어(의미가 없는 단어)를 추가하는 방식은 적절하지 못하다.
- 연속적인 숫자를 덧붙인 이름(a1, a2, ..., aN)
- Info나 Data(의미가 불분명한 불용어)
- 변수 이름에 variable을 붙이거나 표 이름에 table을 쓰는 경우
이런 이름은 그릇된 정보를 제공하는 이름도 아니며, 아무런 정보도 제공하지 못한다.
의미가 분명히 다를 경우 접두어를 사용해도 무방하지만 어떤 변수가 존재한다고 해서 해당변수에 접두어를 붙여서 이름을 만들면 안 된다.
-> 읽는 사람이 차이를 알도록 이름을 지어야 한다.
4. 발음하기 쉬운 이름을 사용하라
보통 사람들은 단어에 능숙하며, 우리 두뇌의 상당 부분은 단어라는 개념만 전적으로 처리한다.
프로그래밍은 사회활동이기 때문에 다른 사람과 쉽게 소통하기 위해 발음하기 어려운 이름은 피하도록 한다.
5. 검색하기 쉬운 이름을 사용하라
문자 하나를 사용하는 이름과 상수는 텍스트 코드에서 쉽게 눈에 띄지 않는 문제점이 있다.
만약 문자 하나(혹은 상수)를 사용하는 이름에 버그가 있다면 검색으로 찾아내지 못한다.
-> 간단한 메서드에서 로컬변수만 한 문자를 사용한다, 이름 길이는 범위 크기에 비례해야 한다.
6. 인코딩을 피하라
이름에 인코딩할 정보는 많기 때문에 유형이나 범위 정보까지 인코딩에 넣으면 이름을 해독하기 어려운 문제점이 있다.
아래는 우리가 피해야할 이름이다.
- 헝가리식 표기법과 기타 인코딩 방식
- 멤버 변수 접두어(m_)
하지만 인코딩이 필요한 경우도 있는데 그 중 하나가 인터페이스 클래스와 구현 클래스이다.
둘 중 하나를 인코딩해야 한다면, 인터페이스 클래스 이름에 접두어 'I'를 붙이는 것보다 구현 클래스 이름에 "Impl"을 붙이것이 낫다.
7. 자신의 기억력을 자랑하지 마라
독자가 코드를 읽으면서 변수 이름을 자신이 아는 이름으로 변환해야 한다면 그 변수 이름은 좋지 않은 이름이다.
이는, 일반적으로 문제 영역이나 해법 영역에서 사용하지 않는 이름을 선택했기 때문에 생기는 문제다.
전통적으로 루프에서 반복 횟수 변수는 한 글자를 사용하는 경우를 제외하고는 한 글자를 변수로 사용하는 것은 적절하지 않다.
-> 이름은 명료해야 한다.
클래스 이름 (혹은 객체 이름): 명사나 명사구 ( ex. Customer, WIkiPage,...)
메서드 이름: 동사나 동사구
(postPayment, deletePage,...)
(접근자, 변경자, 조건자는 javabean 표준에 따라 값 앞에 get, set, is를 붙인다.)
8. 기발한 이름은 피하라
특정 문화에서만 사용하는 농담을 이름으로 하는 것은 피하는 것이 좋다.
이는 특정 소수만 알 수 있게 된다.
- kill() 대신에 whack()을 사용하는 경우
- Abort() 대신에 eatMyShort()를 사용하는 경우
-> 의도를 분명하고 솔직하게 표현해야 한다.
9. 한 개념에 한 단어를 사용하라
추상적인 개념 하나에 단어 하나를 선택해 이를 고수해야 한다.
만약 추상적인 개념 하나에 단어 하나를 선택하지 않는다면 아래와 같은 문제가 생긴다.
- 똑같은 메서드를 클래스 마다 fetch, retrieve, get으로 이름을 정한 경우
- 동일 코드 기반에서 controller, manager, driver를 섞어서 쓰는 경우
-> 일관성 있는 어휘를 사용해야 한다.
10. 말장난을 하지 마라
한 단어를 두 가지 목적으로 사용하면 안 된다. 다른 개념에 같은 단어를 사용한다면 그것은 말장난에 불과하다.
(ex. add메서드가 기존 값 두 개를 더하거나 이어서 새로운 값을 만들 때, 집합에 같은 값 하나를 추가하는 메서드 이름을 add로 하는 경우, 이는 기존의 add 메서드와 다른 맥락이기 때문에 insert나 append라는 이름을 사용하는 것이 좋다)
-> 프로그래머는 코드를 최대한 이해하기 쉽게 짜야한다. (대충 훑어봐도 이해할 코드가 코드 작성의 목표)
11. 해법 영역에서 가져온 이름을 사용하라
코드를 읽을 사람도 프로그래머라는 사실을 명심해야 한다. 전산 용어, 알고리즘 이름, 패턴 이름, 수학 용어 등을 사용하는 것은 괜찮다.
하지만, 모든 이름을 문제 영역에서 가져오는 정책은 현명하지 못하다.
-> 기술 개념에는 기술 이름이 가장 적합한 선택이다.
12. 문제 영역에서 가져온 이름을 사용하라
적절한 '프로그래머 용어'가 없다면 문제영역에서 이름을 가져온다.
그러면 코드를 보수하는 프로그래머가 분야 전문가에게 의미를 물어 파악할 수 있게 된다.
우수한 프로그래머는 문제영역과 해법영역을 구분할 줄 알아야 한다.
-> 문제 영역 개념과 관련이 깊은 코드는 문제 영역에서 이름을 가져와야 한다.
13. 의미 있는 맥락을 추가하라
대다수의 이름은 스스로 의미가 분명한 이름이 없기 때문에 클래스, 함수, 이름 공간에 넣어 맥락을 부여한다.
만약 모든 방법이 실패할 경우, 마지막 수단으로 접두어를 붙인다.
(ex. firstName, lastName, street, houseNumber, city, state, zipcode라는 변수가 같이 있다면 주소와 관련이 있는 변수를 알 수 있지만, 어느 메서드가 state 변수 하나만 사용하면 변수 state가 주소 일부라는 사실을 알기 어렵다. 이때 addr이라는 접두어를 모든 변 수명에 추가한다면 맥락이 분명해진다. 하지만 더 좋은 방법은 Address라는 클래스를 생성하여 관련 변수들을 해당 클래스에 넣는 것이 다.)
14. 불필요한 맥락을 없애라
예를 들어, 고급 휘발유 충전소(Gas Station Deluxe)라는 애플리케이션을 짠다고 가정해보자.
모든 클래스 이름을 GSD로 시작한다면 IDE에서 G를 입력하고 자동완성 키를 누르면 모든 클래스가 열거된다.
이로 인해 IDE를 제대로 사용할 수 없게 된다.
하지만 일반적으로 의미가 분명한 경우, 짧은 이름이 긴 이름보다 좋다.
마치면서
대부분의 사람들은 자신이 짠 클래스 이름과 메서드 이름을 모두 암기하지 못한다. 그렇기 때문에 암기는 도구에게 맡기고, 우리는 문장이나 문단처럼 읽히는 코드나 적어도 표나 자료 구조처럼 읽히는 코드를 짜는데 집중해야 한다.
즉, 코드 가독성이 높아지도록 코드를 짜는데 노력해야 한다.
'Clean Code' 카테고리의 다른 글
| Chapter7 오류 처리 (0) | 2022.02.09 |
|---|---|
| [Clean Code] Chapter 6 객체와 자료구조 (0) | 2022.02.02 |
| [Clean Code] Chapter 5 형식 맞추기 (0) | 2022.01.25 |
| [Clean Code] Chapter 4 주석 (0) | 2022.01.20 |
| [Clean Code] Chapter 3 함수 (0) | 2022.01.11 |
