[BOOK : 클린코드 2장] 의미있는 이름

 

 

2장은 우리가 변수명, 클래스 명 등 각 이름들을 붙일 때 어떻게 붙여야 하는지에 대해 이야기해주고 있었다.

 

물론, 하나하나 전부 중요하긴 하지만 나는 해당 챕터를 읽었을 때 다음과 같이 생각을 하였다. 

 

• 직관적이고 명확하게 표현해야 한다. 

각 변수 그리고 메서드들이 어떤걸 표현해야 하는지에 대해 명확하게 표현되어야 한다라고 생각했다.

 

이렇게 생각을 하다보니, 코드 컨벤션과도 엮어 생각해볼 수도 있었다. 

 

코드 컨벤션 또한 누구나 쉽게 코드를 이해하고 사용할수 있게끔 즉, 해당 코드를 이해할 수 있게끔 하는것이 목표이기 때문이다. 

 

해당 부분에 대해서 만약 다른 의견이 있다면 그 의견도 한번 들어보고 싶다. 

 

해당 책에서는 다음과 같이 의미 있는 이름들을 이야기해주고 있었다. 

 

 

의도를 분명하게 밝혀라 

• 좋은 이름을 지으려면 시간이 걸리지만 좋은 이름으로 절약하는 시간이 훨씬 더 많다.
• 그렇기에, 이름을 주의 깊게 살펴 더 나은 이름이 떠오르면 개선해야 한다. 

 

그릇된 정보를 피하라

• 프로그래머는 코드에 그릇된 단서를 남겨서는 안 된다.
• 그릇된 단서는 코드의 의미를 흐리게 된다. 
• 나름대로 널리 쓰이는 의미가 있는 단어를 다른 의미로 사용해도 안된다. 
• 서로 흡사한 이름을 사용하지 않도록 주의한다. 
• 유사한 개념은 유사한 표기법을 사용한다. 

 

의미 있게 구분하라

• 컴파일러나 인터프리터만 통과하려는 생각으로 코드를 구현하는 프로그래머는 스스로 문제를 일으킨다. 
• 명확한 관례가 없다면 변수와 구분이 안된다. 고로 읽는 사람이 해당 차이를 명확하게 알도록 이름을 지어야 한다.

 

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

• 말을 처리하기 위해, 발달한 두뇌를 활용하지 않는다면 안타까운 손해이다.
• 우리 뇌는 상당 부분 단어라는 개념만 전적으로 처리한다.
• 토론 시, 해당 단어의 발음이 어려워 지장이 생기면 안 된다. 프로그래밍은 사회 활동이다.

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

• 문자 하나를 사용하는 이름과 상수는 텍스트 코드에서 쉽게 눈에 띄지 않는다는 문제점이 있다. 
• 이름 길이는 범위 크기에 비례해야 한다.

인코딩을 피하라 

• 유형이나 범위 정보까지 인코딩에 넣으면 그만큼 이름을 해독하기 어려워진다.
• 새로운 개발자가 익힐 코드 양은 상당히 많은데, 여기다 인코딩 '언어'까지 익히라는 요구는 비합리적이다.
• 문제 해결에 집중하는 개발자에게 인코딩은 불필요한 정신적 부담이다.
• 인코딩한 이름은 거의가 발음하기 어려우며 오타가 생기기도 쉽다
  • 발음하기 쉬운 이름을 사용하라에 위반이라고 생각이 들었다.

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

• 자신만이 아는 이름으로 이름을 짓는 행동은 바람직하지 못하다.
• 똑똑한 프로그래머와 전문가 프로그래머 사이에서 나타나는 차이는 명료함이 최고라는 사실을 이해한다. 
• 전문가 프로그래머는 자신의 능력을 좋은 방향으로 사용해 남들이 이해하는 코드를 내놓는다.

클래스 이름 

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

메서드 이름 

• 메서드 이름은 동사나 동사구가 적합하다.
• 접근자 , 변경자 , 조건자 , javabean 표준에 따라 값 앞에 get, set , is를 붙인다.

 

기발한 이름은 피하라 

• 재미난 이름보다는 명료한 이름을 선택하는 것이 좋다! 
• 간혹 프로그래머가 나름대로 재치를 발휘해 구어체나 속어를 이름으로 사용하는 사례 (ex. kill 대신 whack ) 
• 특정 문화에서만 사용하는 농담은 피하는 편이 좋다.
• 의도를 분명하고 솔직하게 표현하라 

 

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

• 추상적인 개념 하나에 단어 하나를 선택해 이를 고수한다.
• 일관성이 있는 어휘는 코드를 사용할 프로그래머가 반갑게 여길 선물이다.

 

말장난을 하지 마라 

• 한 단어를 두 가지 목적으로 사용하지 마라 
• 다른 개념을 같은 단어를 사용한다면 그건 말장난에 불과하다.
• 프로그래머는 코드를 최대한 이해하기 쉽게 짜야한다.
• 집중적인 탐구가 필요한 코드가 아닌 대충 훑어봐도 이해할 코드 작성이 목표다.
• 의미를 해독할 책임이 독자에게 있는 논문 모델이 아닌 의도를 밝힐 책임이 저자에게 있는 잡지 모델이 바람직하다.

 

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

• 코드를 읽을 사람도 프로그래머라는 사실을 명심해야 한다.
• 모든 이름을 문제 영역에서 가져오는 정책은 현명하지 못하다.

 

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

• 적절한 '프로그래머 용어'가 없다면 문제 영역에서 이름을 가져온다.
• 문제 영역 개념과 관련이 깊은 코드라면 문제 영역에서 이름을 가져와야 한다.

 

의미 있는 맥락을 추가하라 

• 스스로 의미가 분명한 이름이 없지 않지만, 대다수 이름은 그렇지 못하다. 
• 클래스, 함수, 이름 공간에 넣어 맥락을 부여한다.
• 모든 방법이 실패하면 마지막 수단으로 접두어를 붙인다. 

 

불필요한 맥락을 없애라 

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

 

좋은 이름을 붙이려면 설명 능력이 뛰어나야 하고 문화적인 바탕이 같아야 하는데, 이가 제일 어렵다고 한다.

 

좋은 이름을 붙이는 건 단기적인 이점도 있지만 장기적인 이점이 크다. 

 

사실 공감하는 바이다. 현재 제대로 이를 읽고 이행하기 위해선 좀 더 신경 써서 변수명을 붙이는데 더 힘써야겠단 생각이 들었다.