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

Bam·2023년 1월 12일

CLEAN CODE 변수 변수명 클린 코드

책꽃이

목록 보기

2/8

인용구(지금 이 문장이 작성된 텍스트 박스)와 말풍선 이모지(💬)가 함께 쓰인 구절은 책에 직접 적힌 내용이 아닌, 제가 읽고 생각한 내용을 작성한 구간입니다.

1장 클린 코드

클린 코드를 작성하기 위한 조언들을 바로 시작하지 않는다. 먼저 클린 코드가 무엇이고, 우리가 왜 클린 코드를 작성해야하는지에 대해 약 20페이지를 할애하고 있다.

책에서 소개하는 클린 코드(Clean Code)란? 💬
프로그래머마다 다양한 정의를 내리지만 종합해보면, 읽기 쉬운 코드라 클린 코드

더러운 코드를 작성해서 망해버린 회사 이야기, 유지보수에서 더러운 코드를 만났을 때 얼마나 불필요한 시간과 노력들이 소모되는 지 등의 사례들을 나열하며 왜 우리가 클린 코드를 작성해야하는 지에 대해 이야기한다.

왜 클린 코드를 작성해야 하는가? 💬

생산성 증가

쉬운 유지보수

읽기 쉬운 코드

또한 이 책을 단순히 완독하면 우리가 클린 코드를 작성할 수 있는 능력이 함양되는 것이 아니라 실제로 코드를 읽어보고, 작성해보고, 고쳐봐야 클린 코드를 작성하는 능력이 길러 진다는 것도 알려주고 있다.

2장 의미 있는 이름

책은 Java 언어를 사용했고, 저는 Javascript를 사용하고 있습니다. 따라서 예시로 제시되는 코드들은 책과 다르게 자바스크립트를 사용해서 표현하도록 하겠습니다.

의도를 밝혀라

변수, 함수, 객체, 모듈이 무슨 역할을 하는지 이름에서 알 수 있도록 하라

변수 등의 이름을 지을 때 그 변수 등이 무슨 의도를 갖는지 이름에 나타낸다면 코드를 읽어내는 수고를 크게 덜을 수 있다. 여기서 말하는 의도는 해당 변수 등의 존재 이유, 수행하는 일, 사용 방법들을 의미한다.

아래 코드는 현재 시각을 구하고 출력하는 아주 단순한 코드이다.

const d = () => {
    let date = new Date();

    return date.toLocaleString();
};

console.log(d());

방금 읽을 때 무척이나 간단한 코드지만 4줄을 전부 읽게 된다. 그 이유는 함수명 d때문일 것이다. d라는 이름만 가지고서는 이 함수가 무슨일을 하는지 전혀 의도를 알 수가 없기에 함수의 내용을 일일이 다 들여봐야하는 수고로움이 발생하게 된다.

위 코드를 의도가 알기 쉬운 코드로 바꾸면 다음과 같다.

const getCurrentDate() => () => {
  let date = new Date();
  
  return date.toLoacleString();
};

console.log(getCurrentDate());

함수명만을 변경했음에도 불구하고, 함수 내용은 읽지 않고 이 함수과 무슨 일을 수행하는지 쉽게 파악하고 코드를 읽어나갈 수 있게 되었다.

그릇된 정보를 피하라

모호하게 해석될 수 있는 여지가 있는 이름들은 피하라.
+ 일반적으로 통용되는 의미가 있는 단어를 다른 의미로 사용하지 마라.

hp라는 단어가 있다. 이 단어를 보면 어떤 사람은 컴퓨터 회사인 hp를, 어떤 사람은 게임에서 사용되는 체력이라는 의미의 hp를 떠올릴 것이다. 이처럼 단어 하나를 가지고 모호하게 해석될 여지가 있는 이름의 사용을 피할 것을 이야기하고 있다.

서로 다른 모듈 단위에서 비슷한 이름을 사용하지 말 것도 이야기하고 있다. 유사한 개념은 유사한 이름을 갖도록 하고, 다른 개념이라면 다른 이름을 갖게 해야한다.

또 소문자 l과 대문자 O는 변수명으로 적합하지 않다는 것이다. l은 1과 O는 0와 비슷하기 때문에 자칫하다간 큰 오류를 범할 수 있기 때문이다.

의미 있게 구분하라

이름에 연속된 숫자나 불용어를 사용하는 것은 바람직하지 못하다.

num1, num2, num3, ...처럼 연속된 숫자를 사용하는 경우 '숫자'라는 정보는 전달이 되지만, 이들이 각각 무슨 일을 하는 지에 대한 '의도'가 담기지 않는 무의미한 이름이 된다.

다음으로는 불용어인데, 불용어란 단어의 실제 의미에서 아무런 기여가 없는 단어를 의미한다. 다시말해 이 단어가 있으나 없으나 단어 해석에 큰 차이가 없는 것들을 불용어라고 한다.

예를들어 학생 객체를 만들 때, StudentInfo라는 이름을 짓느니 그냥 Student라고 적어버리는게 낫다는 것이다.

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

발음하기 쉬운 이름은 생각할 때도, 사용할 때도 이해시키기 좋다.

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

검색하기 쉬운 단어를 사용하자.

a라는 변수명을 가진 변수를 찾기위해 프로젝트를 열고 'a'를 검색하면 'a'가 들어가는 모든 이름들이 검색된다. (apple, ant, happy, heat, aaa 등) 이렇게 된다면 검색 효율이 떨어지기 때문에 검색에 쉽게 잡힐 키워드나 이름 자체를 사용해야한다.

인코딩을 피하라

인코딩된 이름은 읽기도 해석하기도 어려우니 피하라.

헝가리안 표기법 X

헝가리안 표기법은 변수 이름 앞에 해당 변수의 타입을 적는 것이다. 최근의 언어들(타입스크립트 같은)이나 IDE가 타입을 잘 캐치해주기 때문에 헝가리안 표기법의 사용을 지양해야한다.

멤버 변수 접두어 X

인터페이스 접두어 I 사용 지양

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

자신만이 아는 단어를 이름으로 사용하지마라

address라는 단어가 치기 귀찮다고, a를 사용하지 말라는 의미이다. 본인이야 알겠지만 코드를 읽는 사람은 이런 이름이 무엇을 의미하는지 알 수 없다. 무엇보다 자신도 나중에 봤을 때 이게 무엇인지 잃어버린다면 큰 낭패를 보게 된다.

※ 단, 반복문의 루프 변수 i, j, k는 암묵적 약속이므로 괜찮다.

클래스와 메소드 이름

클래스 명은 명사나 명사구

예) Customer, Page, Account 등

메소드 명은 동사나 동사구

예) getCost, setName, reloadPage, save 등

기발한 이름은 피하라

일반적으로 통용되는 명료한 이름을 사용하라

유머 넘치는 이름은 그 역할을 알기 어려울 수도 있다. pageCutter라는 이름보다 deletePage라는 이름이 명료하다.

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

추상적 개념 하나에 하나의 단어만을 고수해라 (일관성 유지)

어떤 정보를 가져올 때, 어떤 메소드에서는 fetch라는 동사구를, 어떤 메소드에서는 get이라는 동사구를 섞어 쓰면 혼란을 야기한다. 하나의 단어를 정해서 그 단어만 쓰도록 해야한다. 그러지 않을경우 일일이 해당 메소드들과 연관 코드들을 다 살펴보아야 한다.

말장난을 하지 마라

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

이전에 언급한 추상적 개념이 같으면 하나의 단어를 써야하지만 다르다면 다른 단어를 사용하라는 의미이다. 개념이 다른데 같은 단어를 쓰는 경우 독자에게 큰 혼란을 줄 수 있다.

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

코드를 읽는 사람들도 프로그래머다. 따라서 문제보단 해법 영역의 단어를 사용하는 것이 좋다.

작업 대기 줄이라는 단어를 표현하고 싶을 때 teskWating이라는 것 보다 taskQueue가 더 명료하다. 왜냐하면 코드를 읽는 사람들도 프로그래머일 것이고, 'Queue'를 모르는 프로그래머는 없을 것이기 때문이다. 이런느낌으로 문제 영역(문제에서 주어지는 일상적인 단어)의 단어보다 해법 영역(기술적 용어)의 단어들을 사용하는 것이 좋다.

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

적절한 해법 영역의 용어(기술적 용어)가 없다면 문제 영역에서 가져오도록 한다.

우선 단어를 해법 영역에서 가져오도록 노력한 후 적절한 단어가 없다면 문제 영역에서 가져오도록 한다. 이렇게 하면 상관없는 단어를 사용했을 때 보다 프로그래머가 분야의 전문가에게 질문해서 그 의미를 파악하기 쉬워질 것이다.

의미 있는 맥락을 추가하라

의미 있는 맥락은 그 뜻을 더욱 분명하게 해준다.

어떤 변수를 만들고, 변수명을 지어서 의미를 부여한다. 하지만 이것으로 충분치 못할 때 클래스, 함수 등에 넣어서 맥락을 부여하도록 한다.

만약 맥락을 부여해도 의미가 모호해진다면, 의미있는 접두어를 붙이도록 한다.

예)
name, street, city, state라는 변수가 모여있으면 주소 정보라는 사실을 알 수 있다. (맥락이 분명하다.) 하지만 특정 메소드에서 state라는 변수만을 사용하면 이 state가 무엇을 의미하는지 정확히 알기 어렵다. (맥락이 불분명 하다.) 따라서 이런 경우에 주소를 의미하는 접두어 'addr-'을 붙여 addrName, addrStreet, addrCity, addrState로 만들면 의미를 파악하기가 쉬워진다.

불필요한 맥락을 없애라

이름의 의미가 분명한 경우 불필요한 맥락을 더하지 않도록 주의한다.

1~2장 후기

코드를 읽을 때 가장 먼저 보게 되는 이름에 대해서 먼저 다루었다. 읽다보면 "어? 당연한 소리아닌가?"싶지만 내 코드를 보면 정작 그렇지 못함을 느낄 수 있었다. 그만큼 당연하지만 지키기 어려우면서도 기본중의 기본이라는 의미라고 생각된다.

혼자서 코드를 짤 때, 특히 블로그에 올리기 위한 코드를 짤 때 이름을 선정하는데 항상 고민했다. 어떻게 해야 의미를 쉽게 전달할 수 있을까? 어떻게 해야 방해되지 않고 적절한 이름을 사용할 수 있을까?하고. 이제는 이 책을 읽은 만큼 의미가 명확한 이름을 지을 수 있도록 노력을 해야겠다고 생각했다. 그러기 위해서는 반복해서 읽고, 여러 이름들을 고민해보고 많은 노력들을 들여볼 예정이다.

Bam

이전 포스트

[Clean Code] 클린 코드

다음 포스트