Clean Code 02 : 이름 짓기

date
Feb 4, 2022
slug
cleancode-02
status
Published
tags
cleancode
architecture
summary
프로그래머는 코드에 그릇된 단서를 남겨서는 안 된다. 나름대로 널리 쓰이는 의미가 있는 단어를 다른 의미로 사용해서도 안된다.
type
Post
notion image

의미 있는 이름

소프트웨어에서 이름은 무조건 쓰인다. 변수, 함수, 인수, 클래스, 패키지 등 안쓰는 곳이 없다. 여기저기 도처에서 개발자는 작명을 하기 때문에 작명을 잘 하면 그만큼 효율적이다.

의도를 분명하게

해당 함수든, 인수든, 변수든 뭐든간에 이름에서 의도를 분명히 밝혀야 한다. 좋은 이름을 지으려면 시간이 걸리지만 좋은 이름으로 절약하는 시간이 훨씬 더 많다.
프로젝트가 진행되는 도중이라도 더 나은 이름이 떠오르면 개선하여 사용하는 것도 좋다.
이런 코드는 아무런 의미도 드러나지 않는다. 도대체 뭐하는 변수인지 코드 전체를 훑어야 이해할 수 있다.
이렇게 의도가 드러나는 이름을 사용하면 누구나 봐도 이해가 쉽다.
복잡한 코드의 맥락이 코드 자체에 명시적으로 드러나지 않는다. 따라서 각 변수에 이름만 설명해도 코드가 나아진다.

그릇된 정보는 배제

프로그래머는 코드에 그릇된 단서를 남겨서는 안 된다. 나름대로 널리 쓰이는 의미가 있는 단어를 다른 의미로 사용해서도 안된다.
예를 들어 실제 List가 아닌데도 여러 계정을 그룹으로 묶었다고 accountList라고 명명하면 안된다.
유사한 개념은 유사한 표기법을 사용한다. 이것 또한 정보다. 일관성이 떨어지는 표기법은 그릇된 정보다.
또한, 헷갈리는 알파벳은 피해야한다. 소문자 L이나 대문자 O는 숫자와 헷갈리기 때문에 자제해야한다. 이 코드를 처음 보는 입장에서 이해해야 한다.

의미 있게 구분

컴파일러나 인터프리터만 통과하려는 생각으로 코드를 구현하려고 하면 문제가 생긴다. 컴파일러를 통과하더라도 연속된 숫자를 붙이거나 사용하지 않는 언어를 사용하는 것은 적절하지 않다.
여기서 a1, a2는 코드를 해석하는 사람으로 하여금 전혀 의미를 이해시키지도 않았다. 그릇된 정보는 아니지만 아무런 정보를 제공하지 않는 것 또한 문제다.
개발자는 코드에서 최대한 정보를 제공할 필요가 있다.
가끔 노력한 구분이 있다
도대체 3개의 함수가 어떤 기능으로 차이가 있는지 구분할 수 없다. 읽는 사람이 차이를 알도록 최대한 정보를 주는 이름으로 지어야한다.

발음하기 쉬운 이름

사람들은 단어에 능숙하다. 기본적으로 발음하기 쉬운 이름을 선택한다. 발음하기 어려운 이름은 토론하기도 어렵다.
"흠, 여기 비 씨 알 3 씨 티 피 에스 지 큐 int가 있군요, 보입니까?"
발음하기 쉬운 이름은 중요하다. 프로그래밍은 사회 활동이기 때문이다.
무리한 약어 또한 문제이다
어떤 회사는 이런 단어를 사용했는데, 직원들이 발음하기를
"젠 와이 엠 디 에이취 엠 에스"
라고 발음했다. 참 비효율적이지 않은가?

검색하기 쉬운 이름

검색하기 쉬운 이름이 상수보다 좋다. 이름 길이는 범위 크기에 비례해야한다.
간단한 반복문에서 sum 같은 변수보다는
같은 검색으로 쉽게 찾을 수 있는 이름이 필요하다.

인코딩을 피해야

모든 변수에 접두어 m_ 같은 것을 붙인다면 가독성이 떨어진다. 사람들은 접두어를 무시하고 이름을 해독하려고 할 것이다. 구닥다리 코드인 것이다.
IShapeFactory에서 I같은 것 또한 필요 없다. 읽는 사람의 주의를 흐트리는 과도한 정보를 제공하는 것은 좋지 않다.

한 개념에 한 단어

동일 코드 기반에 controller, manager, driver를 섞어 쓰면 혼란스럽다.
DeviceManagerProtocolController는 근본적으로 어떻게 다른지 전혀 설명되지 않는다.
이름이 다르면 독자는 클래스도 다르고 타입도 다르다고 생각한다. 따라서 동일한 코드가 기반이면 이름을 통일하여야 한다.

말장난 금지

한 단어를 두가지 목적으로 사용하면 안된다.
어떤 두 함수(기존 값 두개를 더하는 함수, 이어서 새로운 값을 만드는 함수)를 개발자가 일관성을 고려해 같은 맥락이 아닌데도 add라는 단어를 이용하려면 문제다.
같은 맥락이 아니기 때문에 코드를 읽는 독자는 이해를 제대로 할 수 없다. 따라서 insertappend 단어를 사용하는 것이 적절하다.
프로그래머는 코드를 최대한 이해하기 쉽게 짜야한다. 대충 훝어봐도 이해할 코드 작성이 목표다.

프로그래머 전용 단어 사용

코드를 읽는 사람도 일반인이 아닌 프로그래머라는 사실을 생각한다. 전산 용어, 알고리즘 이름, 패턴 이름, 수학 용어 등을 사용해도 괜찮다.
기술 개념에는 기술 이름이 가장 적합한 선택이다.

맥락 고려

의미 있는 맥락은 추가해야한다. 변수가 전부 주소에 관한 변수라면 addr라는 접두어를 추가하여 맥락을 분명히 할 수 있다.
그러나 불필요한 맥락은 제거해야한다. 고급 휘발유 충전소(Gas Station Deluxe)라는 애플리케이션을 만든다고 모든 클래스 이름을 GSD로 시작하는 것은 바람직하지 않다.
IDE에서 G를 검색하면 모든 클래스를 열거할 것이다. 개발자를 지원하는 IDE를 방해할 이유가 없다.
일반적으로 짧은 이름이 긴 이름보다 좋은데, 의미가 분명한 경우에 한한다.

© jadru 2022 - 2024