[클린 코드] #2 의미 있는 이름

 

클린 코드 #2 의미 있는 이름

#클린코드

이름을 잘 붙이는 규칙에 대해 알아보자.

의도를 분명히 밝히자

좋은 이름을 지으는데 오래 걸리더라도, 좋은 이름으로 절약하는 시간이 훨씬 더 많다.

이름을 지을 때는 다음과 같은 질문에 모두 답할 수 있어야 한다.

• 변수/함수/클래스의 존재 이유는?
• 수행 기능은?
• 사용 방법은?

만약 주석이 필요하다면 의도를 분명히 드러내지 못했다는 말이다.

ex) 경과 시간, 경과 날짜

int elapsedTimeInDays

측정하려는 값과 단위를 표현하는 이름이 필요하다.

코드 맥락이 들어나게끔 이름을 작성하자.

함축적이고 명시적이지 않은 정보를 드러냄으로써 코드가 명확해질 수 있다.

그릇된 정보를 피하자

그릇된 단서를 코드에 남기면 안 된다.

널리 쓰이는 의미가 있는 단어를 다른 의미로 사용해도 안 된다.

• ex) accountList
  • 계정을 묶은 목록을 의미하지만 실제 List가 아니라면 사용하면 안 된다.

흡사한 이름을 사용하지 않도록 주의하자.

다만 유사한 개념은 유사한 표기법을 사용하자. 일관성있는 표기법을 사용하라는 의미이다.
특히, 대문자 1개로 int L, int O 이런 건 피해야 한다.

의미 있게 구분하라

컴파일러나 인터프리터만 통과하려는 생각으로 코드를 구현하지 말자.

예시 상황
변수 명을 a1, a2… 이런식으로 막 적었다고 해보자. 만약 a1을 a2로 바꿔버린다면 오류가 발생할 것이다.

연속된 숫자를 덧붙이거나 불용어를 추가하는 방식은 적절하지 않다.
이름이 달라야 한다면, 의미도 달라져야 한다.

예시)
Product라는 클래스가 존재할 때, ProductInfo 혹은 ProductData는 이름만 다르고 의미는 같은 경우이다.
Info나 Data는 의마가 불분명한 불용어이다.

변수 이름에 variable을 붙이거나, 표 이름에 table을 붙이는 등 불용어를 사용하지 말자.
CustomerObject, NameString 이런 표현은 사용하지 말아야 한다.
만약 Name, NameString이 있다면 개발자는 어떤 것을 사용해야 할 지 혼동이 올 것이다.

읽는 사람이 차이를 알도록 이름을 지어야 한다.

발음하기 쉬운 이름을 사용하라

프로그래밍은 사회 활동이다. 발음하기 쉬운 이름을 사용해야 한다.

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

문자 하나를 사용하는 이름과 상수는 텍스트 코드에서 쉽게 눈에 띄지 않는다.
ex)MAX_CLASSES_PER_STUDENT를 검색할 때와, 숫자 7을 검색할 때와 어떤 것이 더 편할 지 생각해봐라.

정말 간단한 메서드에서는 로컬 변수로 한 문자를 사용하자. 이름의 길이는 범위 크기에 비례해야 한다.
여러 곳에서 변수나 상수를 사용한다면 검색하기 쉬운 이름을 사용해야 한다.

인코딩을 피하라

타입이나 범위 정보를 인코딩에 넣으면 해독하기 어려워진다. 인코딩 정보까지 이름에 넣으면 안 된다.
객체는 강한 타입이기 때문에 IDE가 타입을 잘 감지해준다.
+ 멤버 변수 접두어는 구닥다리 코드다.

인터페이스 클래스와 구현 클래스

가끔 인코딩이 필요한 경우도 있다. 인터페이스와 구현 클래스를 사용하는 경우이다.
인터페이스의 존재 이유를 고려할 때, 인터페이스의 이름을 수정하는 것 보단 구현 클래스의 이름을 인코딩하는게 옳다. ShapeFactory라는 인터페이스가 있다면, 구현 클래스는 ShapeFactoryImpl로 사용할 수 있다.

자신의 기억력을 자랑하지 말자

독자가 코드를 읽으면서 변수 이름을 자신이 아는 이름으로 변환해야 한다면 그 변수 이름은 바람직하지 못하다.

for문 같이 범위가 아주 작은 곳에서 반복 횟수를 세는 i, j, k는 괜찮다. 그 외에는 최악이다. i, j, k를 실제 개념으로 변환해야 하기 때문이다.

명료함이 최고이다.

클래스 이름

클래스 이름과 객체 이름은 명사나 명사구가 적합하다.

예시

• Customer
• Account
• AddressParser

Manager, Processor, Data, Info와 같은 단어는 피하고, 동사는 사용하지 않는다.

메서드 이름

메서드 이름은 동사나 동사구가 적합하다.
postPayment, deletePage, save 등이 좋은 예시이다.

접근자, 변경자, 조건자는 자바 빈 표준에 따라 값 앞에 get, set, is를 붙여준다.

생성자 중복 정의

생성자를 중복 정의(overload)할 때는 정적 팩토리 메서드를 사용하자.
메서드는 인수를 설명하는 이름을 사용해야 한다.

Complex flucrumPoint = Complex.FromRealNumber(23.0);
Complex flucrumPoint = new Complex(23.0);

아래보다 위가 좋은 코드이다.

기발한 이름은 피하라

재미난 이름보다 명료한 이름을 선택해야 한다. 특정 문화에서만 사용하는 농담은 피하자.

한 개념에 한 단어를 사용하자.

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

EX) 똑같은 메서드를 클래스마다 fetch, retrieve, get으로 제각각 부르면 혼란스러워진다.
어느 클래스에서 어느 이름을 썼는지 기억하기 어려워진다.

메서드 이름은 독자적이과 일관적이어야 한다. 그래야 프로그래머가 주석을 뒤져보지 않고 올바른 메서드를 선택할 수 있다.

동일 코드 기반에 controller, manager, driver를 섞어 사용하면 혼란스럽다. 이름이 다르다면 독자는 클래스도 다르고 타입도 다르다고 생각할 수 있다.

말장난을 하지 마라

한 단어를 두 가지 목적으로 사용하지 말자. 다른 개념에 같은 단어를 사용하는 것은 말장난에 불과하다.

예시)
지금까지 add라는 메서드 이름을 두 개의 값을 더하거나 이어서 새로운 값을 만드는데 사용했다고 하자.
만약 집합에 새로운 값 하나를 추가하는 메서드를 만든다고 한다면, add라는 이름을 사용해야 할까?
X. insert나 append라는 이름을 사용하자. add를 사용하면 말장난이다.

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

코드를 읽는 사람은 프로그래머다. 전산 용어, 알고리즘 이름, 패턴 이름, 수학 용어 등을 사용해도 괜찮다.
모든 이름을 문제 영역에서 가져오는 것은 현명하지 못하다. 기술 개념에는 기술 이름이 가장 적합하다.

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

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

해법 영역과 문제 영역을 구분해서 이름을 가져와야 한다.

의미 있는 맥락을 추가하라

대다수의 이름은 스스로 의미가 분명하지 않다. 그래서 클래스, 함수, namespace에 넣어 맥락을 부여해야 한다.
이 방법이 모두 실패하면 마지막 수단으로 접두어를 붙이자.

ex)
state라는 변수가 그냥 존재할 때와 Address 클래스 안에 존재할 때 그 차이를 생각해보자.
변수가 조금 더 큰 구조에 속한다는 사실이 적어도 독자에게는 분명해진다.

메서드가 길어지고, 맥락이 불분명한 변수 명은 클래스와 함수 모듈화로 개선할 수 있다.
메서드에 있는 변수가 클래스에 속한다면 맥락이 분명해진다. 이렇게 맥락을 개선하면 함수를 쪼개기가 수월해져서 알고리즘도 명확해진다.

불필요한 맥락을 없애라

만약 고급 휘발유 충전소(Gas Station Deluxe)라는 애플리케이션을 만들 때, GSD로 모든 클래스 이름을 시작하는 것은 전혀 바람직하지 못하다. 고객 관리 프로그램이 추가된다면, GSD를 붙이는게 과연 적절할까?

일반적으론 짧은 이름이 긴 이름보다 좋다. 단, 의미가 분명한 경우에 한해서이다. 이름에 불필요한 맥락을 추가하지 말자.
accountAddress와 customerAddress는 Address 클래스의 인스턴스로는 좋은 이름이지만, 클래스 이름으로는 부적합하다.