Chapter 2. 의미있는 이름

내가 그의 이름을 불러주기 전에는 
그는 다만 하나의 몸짓에 지나지 않았다. 

내가 그의 이름을 불러주었을 때, 
그는 나에게로 와서 꽃이 되었다.

- 김춘수, 꽃

소프트웨어에서의 이름은 어디에나 쓰인다. 우리는 변수에도 이름을 붙이고, 함수에도 이름을 붙이고 인수와 클래스, 패키지에도 이름을 붙인다. 그외 소스파일과 폴더 그 무엇까지.. 이름을 잘 지으면 여러모로 편리하다. 이번 장에선 이름을 잘 짓는 간단한 규칙을 몇가지 소개한다.

의미와 의도를 밝혀라

변수와 클래스 , 의미와 의도가 분명한 이름이라면 절약 되는 시간이 훨씬 더 많다. 그러므로 이름을 주의깊게 살펴 더 나은 이름이 떠오르면 개선되기 쉽다. 그러면 코드를 읽는 사람이 좀 더 행복해 지리라.

의도가 드러나는 이름을 사용하면 코드이해와 변경이 쉬워진다. 단순한 코드여도 의도가 드러난 이름을 사용하지 않는다면 짐작하기 어렵다. (책 23Page)

또 프로그래머는 코드에 그릇된 단서를 남겨서는 안된다. 그릇된 단서는 코드의 의미를 흐린다. 나름대로 널리 쓰이는 의미가 있는 단어를 , 다른 의미로 사용해도 안된다.

또 서로 흡사한 이름을 사용하지 않도록 주의해야한다. 조금 떨어진 모듈에서 비슷한 이름을 사용한다면 과연 우리는 그 차이를 쉽게 알아챌 수 있을까?

유사개념은 유사한 표기법을 이용한다. 이것도 정보다. 일관성이 떨어지는 표기법은 그릇된 정보이다. 이름만으로 그릇된 정보를 제공하는 진짜 끔찍한 예가 소문자 'L(l)' 과 대문자 'O(o)' 이다. 두 변수를 한꺼번에 사용하면 정말 끔찍해진다. 소문자 'l'은 숫자 1처럼 보이고 대문자 'O'는 숫자 '0'처럼 보인다.

1. 의미있게 구분하라

컴파일러나 인터프리터만 통과하려는 생각으로 코드를 구현하는 프로그래머는 스스로 문제를 일으킨다. 예를들어 이름을 하나 변경했는데, 그 이름때문에 컴파일러에 통과하지 못할경우 '의미없는 네임밸링'을 하게 된다. (a1,a2,a3...) 이것은 의도적인 이름과 정 반대인것이다.

이런 불용어를 추가하면 아무런 정보를 제공하지 못하며, '중복'에 빠지기 쉽다. 그리고 버그와 오류가 생길때 어디에서 무엇을 고치고 수정해야할지 난감해진다. 대체 어느 함수와 클래스를 뒤져야 빠를까?

또 명확한 관례가 없다면 변수 moneyAmount는 money와 구분이 안된다. customerInfo 는 customer 와, acctountData는 account와 theMessage는 message와 구분이 되질 않는다. 읽는 사람이 차이를 알 수 있도록 이름을 지어라.

2. 발음과 검색하기 쉬운 이름을 사용하라

또 발음하기 쉬운 이름을 사용하는것도 중요하다. 우리 두뇌에서 상당부분은 단어라는 개념만 전적으로 처리한다. 그리고 정의상 단어는 발음이 가능하다. 말을 처리하려고 발달한 두뇌를 활용하지 않는다면 안타까운 손해이다.

발음하기 어려운 이름은 토론하기도 어렵다.

검색하기 쉬운 이름을 사용해야한다. 이것도 마찬가지로 중요한데 가령 문자하나를 사용하는 이름과 상수는 텍스트 코드에 쉽게 눈에 띄지않는 문제점이 있다. 숫자 7을 검색한다면, 파일과 이름 여러 수식이 모두 검색되기 때문에 , 만약 상수 여러자리 숫자이고 누군가 상수 내숫자 위치를 바꿨더라면 문제는 더욱 심각하다. 상수에 버그가 있으나 검색으로 찾아내지 못한다.

검색하기 어려운탓에, 이런 관점에서 긴이름이 짧은 이름보다 좋다. 개인적으로는 간단한 메서드에서 로컬변수만 한 문자를 사용한다. 이름 길이는 범위 크기에 비례해야한다. 변수나 상수코드를 여러곳에서 사용한다면 검색하기 쉬운 이름이 바람직하다.

자신의 기억력을 과신하지 말것

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

일반적으로 프로그래머들은 아주 똑똑하다. 때때로 똑똑한 사람은 자신의 정신적 능력을 과시하고 싶어한다. 가령, 'r' 이라는 변수가 호스트와 프로토콜을 제외한 소문자 URL이라는 사실을 언제나 기억한다면 확실히 똑똑한 사람이다. 하지만 똑똑한 프로그래머와 전문가의 차이점을 하나 든다면 전문가는 명료함을 최고라는 사실을 알고있다.

1. 기발한 이름을 피하라

이름이 너무 기발하고 저자와 유머감각이 비슷한 사람만, 그리고 농담을 기억하고 아는 사람만 그 이름을 기억할 것이다. 재미난 이름보단 의도의 의미가 명로한 이름을 선택하는 것이 좋다.

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

'Controller, Manager, Driver' 를 섞어 쓰면 매우 혼란 스럽다. 'Device Manager'와 'ProtocolController'는 근본적으로 어떻게 다를까? 어째서 왜 둘다 'Controller'가 아니고, 'Manager'가 아닌가 ?

정말 둘다 'Driver'가 아닌가? 이름이 다르면 당연히 클래스도 다르고 타입도 다르리라 생각한다. 일관성 있는 어휘는 코드를 사용할 프로그래머가 반갑게 여길 선물이다.

1. 말장난을 하지마라

한 단어를 두가지 목적으로 사용하지 말아야한다. 다른 개념에 같은단어를 사용한다면 그것은 말장난이다. 하지만 때로는 프로그래머가 같은 맥락이 아님에도 불구하고 일관성을 고려해 단어를 선택한다. 예를들어, 지금까지 구현한 add메서드는 모두가 기존값 두개를 더하거나 이어서 새로운 값을 만든다고 가정한다면, 새로 작성하는 메서드는 집합에 값 하나를 추가한다. 이 메서드를 add라 불러도 괜찮을까?

이것은 말장난 이다. 프로그래머는 코드를 최대한 이해하기 쉽게 짜야 한다. 집중적인 탐구가 필요한 코드가 아니라 대충 훑어 봐도 이해할 코드 작성이 목표다. 의미를 해독할 책임이 독자에게 있는 논문 모델이 아니라 의도를 밝힐 책임이 저자에게 있는 잡지모델이 바람직 하다.

2. 해법 영역과 문제영역에서 가져온 이름을 사용하라

코드를 읽을 사람도 프로그래머이다. 그러므로 전산 용어, 알고리즘 이름, 패턴 이름, 수학 용어 등을 사용해도 괜찮다. 하지만 모든 이름을 전문영역에서 가져오는 정책은 현명하지 못하다.

프로그래머에게 익숙한 기술 개념은 아주 많다. 기술 개념에는 기술이름이 가장 적합한 선택이다.

하지만 적절한 '프로그래머 용어'가없다면 문제영역 에서 이름을 가져올 수 있다. 그러면 코드를 보수하는 프로그래머가 분야 전문가에게 의미를 물어 파악 할 수 있다.

우수한 프로그래머와 설계자 라면 해법영역과 문제영역을 구분할줄 안다.

결론

좋은 이름을 선택하려면 설명 능력이 뛰어나야하고 문화적인 배경이 같아야 한다. 이것이 제일 어렵다. 좋은 이름을 선택하는 능력은 기술, 비즈니스, 관리 문제가 아니라 교육의 문제다. 우리분야의 사람들이 이름짓는 방법을 제대로 익히지 못하는 이유가 바로 여기에 있다.

사람들이 이름을 바꾸지않으려는 이유는 다른개발자가 반대할까 두려워서 이다. 우리는 문장이나 문단처럼 읽히는 코드 아니면 적어도 표나 자료 구조처럼 읽히는 코드를 짜는데만 집중해야한다. 누군가가 질책할 수도 있지만 그렇다고 개선할 노력을 중단해서는 더욱 안된다.

느낀점

이름짓기란 매우중요하다. 이름을 잘짓고 아니고를 떠나 함수와 클래스가 간단하게 작성되어 있어도 우린 그것이 무슨 기능을 하는 함수이고 클래스인지 알 수가 없다.

유지보수를 해야할 사람은 컴퓨터가 아니라 사람이다. 그러므로 이름을 정말 잘 지어야 한다.