[Clean Code]클린코드_2_의미있는 이름

프로그래머가 많은 고민을 하는 부분이 바로 이름을 붙이는 것이다. 우리는 변수에도 이름을 붙이고, 함수에도 이름을 붙이고, 인수와 클래스와 패키지에도 이름을 붙이다. 소스파일에도 이름을 붙이고, 소스 파일이 담긴 디렉토리에도 이름을 붙인다. 이처럼 이름을 붙이는 일이 많으므로 이름을 잘 지으면 가독성도 높아지고 용도도 쉽게 파악이 가능해 이름을 잘 짓는 것이 중요하다.

 

 

우리들 대다수는 자신이 짠 클래스 이름과 메서드 이름을 모두 암기하지 못한다. 암기는 요즘 나오는 도구에게 맡기고, 우리는 문장이나 문단처럼 읽히는 코드 아미녀 적어도 표나 자료 구조 처럼 읽히는 코드를 짜는 데만 집중해야 한다. 다음에 소개한 규칙 몇 개만 적용해도 코드 가독성이 높아지는것을 확인할 수 있을 것이다.

 

 

[ 의도를 분명히 밝혀라 ]

의도가 분명히 드러나는 이름을 짓는 것이 매우 중요하다. 만약 변수나 함수 그리고 크래스 이름만 보고 어디에 사용하는지 존재 이유가 뭔지, 무엇을 수행하는지를 알 수 있다면 매우 좋은 코드가 될 것이다.

물론 좋은 이름을 지으려면 시간이 걸리지만 좋은 이름으로 절약하는 시간이 훨씬 더 많다.

 

 

[ 그릇된 정보를 피해라 ]

프로그래머는 코드에 그릇된 단서를 남겨서는 안된다. 그릇된 단서는 코드 의미를 흐린다.

 

나름대로 널리 쓰이는 의미가 있는 단어를 다른 의미로 사용하면 안 된다.

이는 이를 읽는 사람에게 그릇된 정보를 제공할 수도 있다.

(ex)accountList라 명명했는데 실제 List가 아니라면 이 코드를 읽는 프로그래머들은 착각을 할 수도 있다.)

 

서로 흡사한 이름을 사용하지 않는 것이 좋다.

서로 흡사한 이름은 헷갈릴 수 있기에 구분을 지을 수 있도록 해야 한다.

물론 유사한 개념과 기능을 가진 코드는 유사한 표기법을 사용한다. 물론 일관성이 떨어지는 표기법은 마찬가지로 그릇된 정보이다.

 

[ 의미있게 구분하라 ]

컴파일러나 인터프리터만 통과하려는 생각으로 코드를 구현하는 프로그래머가 있다 생각하자. 예를 들어, 동일한 범위 안에서는 다른 두 개념에 같은 이름을 사용하지 못하기 때문에 이 프로그래머는 한쪽이름만 대충 아무거나 바꾸고픈 유혹에 빠지게 된다. 컴파일러를 통과할지라도 불용어(noise word)를 추가하는 방식은 적절하지 못하다

 

 

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

발음하기 어려운 이름일 수록 기억하기도 어렵고 다른 사람과 토론할 때도 어렵다.

 

 

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

문자하나를 사용하는 이름과 상수는 텍스트 코드에서 쉽게 눈에 띄지 않으므로 검색하기 쉬운 이름으로 사용해야 한다. 예를 들어 'e'라는 문자로 변수를 만들었다고 하자. 그러면 검색할 때 e라고만 검색을 하면 e가 포함된 모든 문장이 등장하여 찾기 어려울 것이다.

 

 

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

독자가 코드를 읽으면서 변수 이름을 자신이 아는 이름으로 변환해야 한다면 그 변수 이름은 바람직하지 못하다. 이는 일반적으로 문제 영역이나 해법 영역에서 사용하지 않는 이름을 자기만의 방식으로 선택했기 때문에 생기는 문제다.

예를 들어 자기가 똑똑하다고 생각하는 프로그래머는 r이라는 변수가 URL을 나타낸다고 의미를 두고 이를 기억하면 코딩을 한다. 하지만 오랜 시간이 흐른 뒤 까먹을 수도 있고 다른 프로그래머가 이 코드를 봤을 때 이해를 못할 가능성이 크다. 하지만 전문가 프로그래머는 명료함이 최고라는 사실을 이해한다. 전문가 프로그래머는 자신의 능력을 좋은 방향으로 사용해 남들이 이해하는 코드를 내놓는다.

 

 

[ 클래스 이름 ]

클래스 이름과 객체 이름은 명사나 명사구가 적합하다. Customer, WoloPage, Account 등이 좋은 예이다.

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

 

 

[ 메서드 이름 ]

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

 

 

[ 기발한 이름은 피해라 ]

재치를 발휘한다고 재미난 이름으로 명명하기보다는 명료한 이름을 선택하고 의도를 분명하게 표현할 수 있는 이름이 좋다.

 

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

추상적인 개념 하나에 단어 하나를 선택해 이를 고수해야 한다. 예를 들어 똑같은 기능을 가진 똑같은 메서드를 클래스마다 get, fetch, retrieve으로 제각각 부르면 혼라스러울 수 있다. 또한 어느 클래스에서 어느 이름을 썼는지도 모르는 경우마저 있다. 따라서 같은 개념은 일관성 있는 어휘를 써 코드를 작성해야 한다.

 

 

[ 말장난을 하지 마라 ]

한 단어를 두 가지 목적으로 사용하지 말아라.

예를 들어 add메서드를 작성했다고 하자. add메서드의 매개변수와 반환값이 의미적으로 모두 똑같다면 상관없지만 기존의 두 값을 더하는 기능이 아닌 add메서드로 집합에 값 하나를 추가하는 메서드를 만들려 한다 생각하자. 이 때 이 메서드를 add라 명명해도 괜찮을까? 아니다 맥락이 다르기 때문에 insert나 append라는 이름이 더 적당하다. 이 메서드를 add라 부른다면 그건 바로 말장난인 것이다.

 프로그래머는 최대한 코드를 이해하기 쉽게 짜야한다.

 

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

코드를 읽는 사람도 프로그래머일 확률이 훨씬 크다. 따라서 전산용어나 알고리즘 이름, 패턴 이름, 수학 용어 등으로 이름을 작성해도 무방하다.

만약 적절한 프로그래머 용어가 없다면 문제 영역에서 이름을 가져와도 된다. 예를 들어 작성하는 애플리케이션에 관련된 분야의 용어가 될 수도 있다.

 우수한 프로그래머와 설계자라면 해법 영역과 문제 영역을 구분할 줄 알아야한다. 문제 영역 개념과 관련이 깊은 코드라면 문제 영역에서 이름을 가져와야 한다.

 

[ 의미있는 맥락을 추가해라 / 불필요한 맥락을 없애라 ]

예를 들어 firstName, lastName, phoneNumber라는 변수를 보면 딱 봐도 성을 의미하는 구나 전화번호를 의미하는 구나라는 것을 알 수 있다. 만약 state라는 변수가 있다면 state가 주소 일부라는 사실을 알 수 있을까? 하지만 여기다 addr라는 접두어를 추가해 addrState라 쓰면 맥락이 좀 더 분명해진다.

 

일반적으로 짧은 이름이 긴 이름보다 좋다. 단 의미가 분명한 경우에 한해서다. 이름에 불필요한 맥락을 추가하지 않도록 주의해야한다.

 

 

[ 인코딩을 피해라 ]