[Clean Code] 2장 의미 있는 이름

728x90

2. 의미 있는 이름

[ 의도를 분명하게 이름을 지으라 ]

- 변수 / 함수 / 클래스 이름은 다음 질문에 모두 답해야 한다

• 변수의 존재 이유는? 수행 기능은? 사용 방법은?

- 코드의 함축성

• 코드는 단순하지만 코드 맥락이 코드 자체에 명시적으로 드러나지 않는다

• 단순히 이름만 고침으로써 함수가 하는 일을 이해하기 쉬워질 수 있다

[ 그릇된 정보를 피하라 ]

- 코드의 의미를 흐리는 그릇된 단서를 코드에 남겨선 안된다

• ex. 실제 List가 아닌데 accountList라 명명하지 않는다

- 널리 쓰이는 의미가 있는 단어를 다른 의미를 사용 ❌

- 서로 흡사한 이름을 사용하지 않도록 주의

- 유사한 개념은 유사한 표기법 사용 : 일관성

• 대부분 개발자는 이름만 보고 객체 선택

• 최신 자바 환경은 코드 자동완성 기능 제공

- 소문자 L / 대문자 O ❌ → 1, 0처럼 보인다

[ 의미 있게 구분하라 ]

- 컴파일러 / 인터프리터만 통과하려는 코드 구현은 문제를 일으킨다

- 연속된 숫자 / 불용어 ❌

• 아무런 정보를 제공하지 못한다

• Info / Data / a / an / the → 의미가 불분명한 불용어

▪︎ a / the 같은 접두어의 의미를 분명히 다르게 사용한다면 무방 ex. 지역변수는 a 사용, 모든 함수 인수는 the 사용

• 불용어는 중복이다 (ex. variable, table)

- 읽는 사람이 차이를 알도록 이름을 지어라

[ 발음하기 쉬운 단어를 사용하라 ]

- 발음이 어려운 이름은 토론하기도 어렵다

• 프로그래밍은 사회 활동이다

[ 검색하기 쉬운 이름을 사용하라 ]

- 문자 하나를 사용하는 이름 / 상수는 텍스트 코드에서 쉽게 눈에 띄지 않는다

- 이런 관점에서 긴 이름 > 짧은 이름

• 검색하기 쉬운 이름이 상수보다 좋다

- 이름 길이는 범위 크기에 비례해야 한다

• 간단한 메서드에서 로컬 변수만 한 문자를 사용한다

[ 인코딩을 피하라 ]

- 굳이 유형이나 범위 정보까지 인코딩에 넣지 않아도 이름에 인코딩할 정보는 아주 많다

- (구)헝가리식 표기법

• 이름 길이가 제한된 언어를 사용하던 옛날에 사용

• 컴파일러가 타입을 점검하지 않아 프로그래머에게 기억할 단서 필요했음

- 자바 프로그래머는 변수 이름에 타입을 인코딩할 필요가 없다

• 이름이나 타입을 바꾸거나 읽기 어려움

- 멤버 변수 접두어 (m_) 필요 ❌

• 멤버 변수를 다른 색상으로 표시하거나 눈에 띄게 하는 IDE를 사용해라

- 인터페이스 클래스 / 구현 클래스 : 인코딩이 필요한 경우

• 둘중 하나를 인코딩해야 한다면 구현 클래스 택하겠다 → ShapeFactory / ShapeFactoryImp

(내가 다루는 클래스가 인터페이스라는 사실을 알리기 싫어)

[ 자신의 기억력을 자랑하지 마라 ]

- 코드를 읽으면서 변수 이름을 자신이 아는 이름으로 변환해야 하는 것은 바람직하지 않다

- 문자 하나만 사용하는 변수 이름 ❌

• 루프에서 반복 횟수를 세는 변수 i, j, k는 루프 범위가 작고 다른 이름과 충돌하지 않을 때 Ok!

- 똑똑한 프로그래머라면 변수의 의미를 기억할 수 있지만, 전문가 프로그래머는 명료함이 최고라는 사실을 이해한다

[ 클래스 / 메서드 이름 ]

- 클래스 / 객체 이름 : 명사나 명사구

• Manager, Processor, Data Info 등과 같은 단어 & 동사 ❌

- 매서드 이름 : 동사나 동사구

• (javabean 표준) 접근자, 변경자, 조건자 → 앞에 get, set, is 를 붙인다

• 생성자 중복정의 → 정적 팩토리 메서드 사용

▪︎ 메서드는 인수를 설명하는 이름 사용

▪︎ 생성자 사용 제한 시, 해당 생성자를 private 선언

[ 기발한 이름은 피하라 ]

- 재미난 이름보다 명료한 이름을 선택하라

- 농담을 기억하는 동안만, 이름을 기억한다

[ 한 개념에 한 단어를 사용하라 ]

- 추상적인 개념 하나에 단어 하나를 선택해 이를 고수한다

- 메서드 이름은 독자적이고 일관적이어야 한다

- 최신 IDE는 문맥에 맞는 단서를 제공한다

• ex. 객체를 사용할 때 객체가 제공하는 메서드 목록 보여준다

[ 말장난을 하지 마라 ]

- 한 단어를 두 가지 목적으로 사용하지 마라

- ex. 두개를 더하거나 이어서 새로운 값을 만드는데 지금까지 사용한 add 메서드

- 집합에 값을 하나 추가하는 add 메서드 ❌ → insert나 append

[ 해법 영역에서 가져온 이름을 사용하라 ]

- 전산 용어, 알고리즘 이름, 패턴 이름, 수학 용어 등을 사용해도 Ok

• 코드를 읽을 사람도 프로그래머

- 기술 개념에는 기술 이름이 가장 적합한 선택

[ 문제 영역에서 가져온 이름을 사용하라 ]

- 적절한 ‘프로그래밍 용어’가 없다면 문제 영역에서 이름을 가져온다

• 보수하는 사람이 분야 전문가에게 의미를 물어 파악 가능

- 우수한 프로그래머 / 설계자는 해법 영역과 문제 영역을 구분하여 이름을 가져올 수 있어야 한다

[ 의미 있는 맥락을 추가하라 ]

- 대다수의 이름은 스스로 의미가 분명한 이름보다는 클래스, 함수, 이름 공간에 넣어 맥락이 부여된다

- 마지막 수단으로 접두어를 붙인다

• ex. firstName, lastName, street, city, state라는 변수 이름을 훑어보면 주소라는 사실을 알 수 있지만, state 변수 하나만 하용한다면 의미를 알 기 어렵다

• → addrfirstName, addrlastName 등으로 접두어를 추가해 맥락을 분명하게 만든다

• 변수가 좀 더 큰 구조에 속한다는 사실에 독자에게 명확해진다

- 클래스를 생성하면 독자에게도 컴파일러에게도 분명해지므로 더 좋다

- 맥락 개선 → 함수 쪼개기 쉬워짐 → 알고리즘 명확

[ 불필요한 맥락을 없애라 ]

- 모든 클래스 이름을 (ex.)GSD 로 시작하겠다는 생각은 바람직 ❌

• IDE에 G를 입력하면 모든 클래스 열거. 개발자를 돕는 IDE를 방해하지 마라

- 의미가 분명한 경우에 한해 일반적으로 긴 이름 > 짧은 이름

- 이름에 불필요한 맥락 추가하지 않도록 주의

[ 마무리 ]

- 좋은 이름을 선택하기 위해서는 설명 능력이 뛰어나고 문화적 배경이 같아야 한다

- 우리는 모든 클래스 / 메서드 이름을 암기하지 못한다

→ 암기는 요즘 나오는 도구에게 맡기자

- 우리는 문장이나 문단처럼 읽히는 코드나 적어도 표나 자료 구조처럼 읽히는 코드를 짜는 데 집중!

📌 Reference : Clean Code - 로버트 C. 마틴