변수명, 함수명, 메서드명, 클래스명 등 - 프로그래밍에서 naming 중요하다는 것은 늘 알고 있었지만,
어떤 이름이 좋은 이름인지, 안 좋은 이름은 왜 안 좋은 이름인지, 좋은 이름을 짓기 위한 어떤 방법이 존재하는 지에 대해서는 잘 알지 못했다. 클린코드 2장을 읽으며 알게 된 내용에 대해 잘 정리해보고, 내가 매일 쓰는 코드들에 적용해보려 한다!
어떤 이름이 좋은 이름인지에 대한 이전 포스팅은 여기!
2023.08.07 - [분류 전체보기] - [🫧CleanCode] 2. 의미 있는 이름 - 분명한 의도 / 그릇된 정보 피하기 / 의미있는 구분
4. 발음하기 쉬운 이름
코드에 쓰이는 이름들은 발음하기 쉬운 이름인 것이 좋다. 단어의 발음이 쉬운 것을 선택하라는 의미보다는 과도한 약어를 사용해서 해당 변수를 읽거나 기억하기 어렵게 하지 말라는 의미이다.
이 책에서는 "프로그래밍은 사회 활동" 이라는 표현을 썼다. 단어가 발음하기 쉬워야 읽기도, 기억하기도, 소통하기도 편하다.
예를 들어, 내가 개발하고 있는 프로젝트에는 youtubeUrlConverter 라는 이름의 함수가 있다. 이 함수의 이름이 ytUrlCvt 이었다면 함수의 이름을 제대로 발음하거나 기억하기 쉽지 않았을 것이다.
5. 검색하기 쉬운 이름
코드에 쓰이는 이름들은 검색하기 쉬운 이름인 것이 좋다.
가장 이해가 쉬운 예를 하나 들어보면 변수 이름이 'e' 라고 해보자. e는 영어에서 가장 많이 쓰이는 문자인데, 이 e라는 변수를 검색하기 위해 IDE 검색 도구에 'e' 를 치면 내가 찾던 그 변수를 찾는 것이 쉬울까?
클린코드에서는 '이름길이는 범위 크기에 비례해야 한다'는 표현을 썼다. 간단한 메서드 하나에 로컬 변수 정도라면 한 글자짜리 변수를 사용해도 무관하다. 이 로컬 변수의 범위가 작기 때문이다. 하지만 좀 더 넓은 범위에서 검색되어야 하는 변수라면 긴 이름이 낫다. 이러한 관점에서 긴 이름이 짧은 이름보다 좋다.
또한 상수를 사용하는 것보다는 변수를 사용하는 것이 낫다. 상수가 변수보다 검색하기 쉽기 때문이다.
이 부분을 읽으며 내가 개발하고 있는 서비스에서 상수로 바꾸면 더 좋을 만한 부분을 찾아보다가 아래의 코드를 발견했다.
new Date(data?.replace("Z", ""));이 Z라는 글자가 무슨 의미인지 의미를 더해주고, 이 Z라는 문자의 검색을 용이하게 만들기 위해 아래와 같이 코드를 바꿔보았다.
const TIME_ZONE_CHARACTER ="Z"
new Date(data?.replace(TIME_ZONE_CHARACTER, ""));
"Z" 라는 상수보다 TIME_ZONE_CHARACTER 이라는 변수가 더 이해하기도 쉽고, 이 값을 찾고자 할 때 검색도 더 쉬워질 것이다!
5. 인코딩 피하기
이 장을 읽으며 인코딩..? 왠 인코딩 ? 을 시전하다가 GPT와 함께 답을 찾았다!
클린코드 저자가 말하는 '인코딩'은 이름의 타입이나 사용처를 나타내기 위해 이름에 부가적인 정보를 더하거나 접두/접미사를 붙이는 것을 의미한다. 예-전에는 컴파일러가 타입을 점검하지 않았기 때문에 개발자가 타입을 기억할 단서가 필요했고 이때문에 변수 내에 타입을 표기하는 헝가리식 표기법을 사용했다.
하지만 요즘의 언어들은 컴파일러가 타입을 기억하고 강제하고, IDE는 컴파일하지 않고도 타입 오류를 감지할 정도로 발전했다. 더이상 변수에 인코딩할 필요가 없다. 게다가 변수에 인코딩을 하게 되면 추후에 변수(또는 함수)의 이름을 바꾸기가 더 어려워진다.
또 다른 인코딩의 예로는 interface 명 앞에 I를 붙이는 옛날 관습이다. (뜨끔.. 얼마전에 인터페이스 앞에 I 붙이면 좋지 않냐고 프론트엔드 네이밍 컨벤션 회의때 얘기했었.. 다행히 다른 분들이 동의하지 않아주셨다.) 이렇게 인터페이스임을 표시하는 I를 붙여봤자 과도한 정보를 제공할 뿐이다.
6. 기억력 자랑 피하기
코드를 읽는 사람이 변수명을 자신이 아는 이름으로 변환해야 한다면, 그 이름은 적절하지 않는 이름인 것이다.
예를 들어, date 값에서 월(month)을 추출하는 함수 이름이 getAfromB() 라고 해보자 (🙀) 그냥 언뜻봐도 별로인 이름이지만 이 이름이 '왜 별로인가' 생각해보면 이유는 '이 코드를 읽는 사람이 A를 month로, B를 date 로 변환해야 하기 때문'이다. 즉 아무 의미도 없는 단어를 실제 개념으로 변환해야 하기 때문이다
대개 문제영역이나 해법 영역에서 사용하지 않은 이름을 선택하는 경우 이렇게 적절하지 않은 이름이 될 가능성이 높다.
📌 문제 영역 / 해법 영역이란?
클린코드 책에서는 '문제 영역'이라는 용어와 '해법 영역'이라는 용어를 사용한다.
문제 영역이란, 도메인 영역, 즉 서비스가 속한 산업군, 비즈니스 영역을 의미한다.
해법 영역이란, 기술 영역'즉 전산/수학 관련 영역을 의미한다.
언제나 좋은 프로그래머는 코드를 명료하게 작성한다. 기억력을 사용하게 하지 말자.
6. 클래스/객체명과 메서드/함수 명
클래스나 객체의 이름으로는 명사나 명사구가 좋다. 이때 명확한 의미가 없는 Manager, Processor, Data, Info 와 같은 단어는 피하자.
메서드나 함수의 이름으로는 동사나 동사구가 좋다. java의 경우 접근자(Accessor), 변경자(Mutator), 조건자(Predicate)의 경우에는 javabean 표준에 따라 get, set, is의 동사로 시작하는 것이 좋다.
다음 포스팅에서는 기발한 이름 피하기 / 한 개념에는 한 단어 / 말장난 피하기 / 해법영역과 문제영역에서 이름 가져오기 / 맥락 더하고 제하기 에 대한 내용을 담아 클린코드 2장을 마무리해보려고 한다!
출처: 로버트 C. 마틴, 『Clean Code』 인사이트, 2022, p27-32
댓글