이름은 작은 설계다
코드에서 이름은 단순한 표시가 아니다. 변수, 함수, 클래스가 무엇을 알고 무엇을 하는지 가장 먼저 설명하는 장치다. 좋은 이름은 주석을 줄이고, 나쁜 이름은 짧은 코드도 어렵게 만든다. 그래서 이름 짓기는 사소한 취향 문제가 아니라 읽기 쉬운 코드를 만드는 핵심 작업이다.
의도를 드러내는 이름은 “무엇을 하는가”뿐 아니라 “왜 필요한가”까지 어느 정도 알려준다. d보다 elapsedTimeInDays가 낫고, getThem보다 getActiveUsers가 낫다. 이름을 길게 쓰는 것이 항상 좋은 것은 아니지만, 짧다는 이유만으로 의미를 생략하면 읽는 사람이 계속 문맥을 추적해야 한다.
헷갈리게 하지 않기
의미 있는 이름을 붙이려면 먼저 잘못된 단서를 피해야 한다. 실제로 리스트가 아닌데 accountList라고 부르거나, 서로 거의 구분되지 않는 data1, data2 같은 이름을 쓰면 코드는 읽는 사람에게 틀린 방향을 가리킨다. 이름은 구현의 세부 구조와 역할을 가능한 정확히 반영해야 한다.
비슷한 개념은 일관된 단어로 표현하고, 다른 개념은 분명히 다른 단어로 구분하는 편이 좋다. fetch, load, get을 섞어 쓰면서 차이가 없다면 읽는 사람은 차이를 찾으려 한다. 반대로 실제 의미가 다르다면 그 차이가 이름에서도 드러나야 한다.
말하고 찾을 수 있는 이름
좋은 이름은 회의 중에 말하기 쉽고, 코드베이스에서 검색하기도 쉽다. 발음하기 어려운 축약어는 팀 안에서 공유하기 힘들고, 한 글자 이름이나 흔한 단어는 검색 결과가 너무 많아진다. 특히 여러 사람이 함께 일하는 코드에서는 이름이 대화의 단위가 된다.
옛날 방식처럼 타입이나 범위를 이름에 억지로 끼워 넣는 방식도 대부분의 경우 도움이 되지 않는다. 언어와 도구가 이미 많은 정보를 제공하기 때문이다. 이름은 부가 정보를 숨기는 암호가 아니라 의도를 드러내는 문장에 가까워야 한다.
기억력에 기대지 않기
나만 아는 약어, 내부 농담, 순간적으로 떠오른 표현은 시간이 지나면 부담이 된다. 코드는 혼자 읽는 글이 아니라 팀과 미래의 내가 함께 읽는 글이다. 이름을 보고 바로 이해되지 않는다면 그 비용은 계속 반복해서 발생한다.
결국 좋은 이름은 대단한 재치보다 꾸준한 정확성에서 나온다. 프로젝트 안에서 같은 개념을 같은 단어로 부르고, 역할이 바뀌면 이름도 함께 바꾸는 습관이 중요하다. 이름을 고치는 일은 작은 리팩터링이지만, 코드 전체의 이해도를 크게 바꾼다.
다음장으로 3장