프로그래머의 뇌 8장 명명을 잘하는 방법

좋은 이름을 사용하면 LTM을 활성화하여 코드 도메인에 대해 이미 알고 있는 관련 정보를 찾을 수 있다. 나쁜 이름은 코드에 대한 잘못된 추측을 하게 하고 오개념을 유발할 수 있다.

이름을 짓는 것은 중요하고 매우 어려운데, 보통 이름은 문제를 해결하는 과정에서 짓기 때문이다. 이 과정은 작업 기억 공간의 부하가 심한 상태이므로, 이 상태에서 좋은 이름을 짓는 것은 부하를 더 가하는 일이기에 우리는 쉬운 이름을 선택하는 경향이 있다

8.1 이름이 중요한 이유

• 이름은 코드베이스의 상당 부분을 차지한다.
• 코드 리뷰 시 이름의 역할
  • 코드 리뷰 4건 중 1건은 명칭과 관련된 언급이 포함되었고, 식별자 이름을 언급한 것은 9%를 차지한다
• 이름은 문서화의 가장 쉬운 형태이다
  • 개발자는 문서를 읽기 위해 코드 밖으로 나가는 것을 피하고 싶어하므로, 코드 내의 주석문과 이름이 가장 많이 읽는 문서이다
• 이름은 표식 역할을 할 수 있다

명명에 대한 다양한 관점

사이먼 버틀러 : 좋은 이름은 문법적으로 정의할 수 있다

• 코드의 불필요한 인지 부하를 줄일 수 있음

알라마니스 : 이름은 코드베이스 내에서 일관성이 있어야한다

• 코드베이스에 거쳐 유사한 객체에 동일한 단어를 사용하면 LTM에 관련 정보를 축적할 수 있다

초기 명명 관행은 지속적인 영향을 미친다

시간 경과에 따른 명명 방식에 대한 조사 결과

• 최신 코드는 명명 지침을 더 잘 따른다
• 그러나 동일한 코드베이스 내에서 명명 관행은 일정하게 유지된다
• 명명 관행 면에서 작은 코드베이스나 큰 코드베이스 사이는 차이가 없다

깃허브의 테스트 사용현황에서는 저장소에 새로 참여한 사람은 프로젝트의 지침을 읽기보다는 기존 테스트를 보고 수정하는 경우가 많다고 한다. 저장소에 테스트가 있을때 새로운 참여자도 테스트를 추가해야하는 부담을 느끼고 프로젝트가 구성되는 방식을 준수한다.

8.2 명명의 인지적 측면

형식이 있는 이름은 STM을 돕는다

• 버틀러 : 문법적으로 비슷한 이름
  • 비슷한 이름들은 관련 정보가 매번 같은 방식으로 제시되기에 이름을 읽는 동안 인지부하가 적다
• 알라마니스 : 코드베이스 내에서의 일관성
  • 청킹에 도움을 줄 수 있다
  • 알라마니스는 내추럴라이즈라는 자바 툴을 개발하였는데, 이 툴은 머신러닝을 통해 코드 내의 일관성 없는 명명 규약을 찾아 낸다. 하지만 코드베이스가 잘못된 규약으로 쓰여진 이름이 많다면 잘못된 이름을 다시 내뱉을 가능성이 크다

명확한 이름은 LTM에 도움이 된다

코드를 읽을때, 변수 이름은 감각 기억에 의해 처리되고 STM으로 전송된다. STM은 크기가 제한되어있기에 변수이름을 단어별로 구분하려고하는데, 이름이 체계적일수록 각 부분으로 구분하기가 쉽다. LTM도 이름과 관련된 사실을 검색한 후 작업 기억 공간으로 보낸다. 이 과정에서 식별자 이름의 단어 선택이 잘 되어있으면 관련 도메인 개념을 LTM에서 잘 찾을 수 있다

변수 이름은 이해에 도움이 되는 다양한 유형의 정보를 포함할 수 있다

• 코드의 도메인에 대해 생각할 때 도움이 된다
• 프로그래밍 개념에 대해 생각할 때 도움이 된다. ex) 트리, 리스트와 같은 개념
• 경우에 따라 LTM이 이미 알고 있는 규약에 대한 정보가 포함될 수도 있다 ex) i, j 등 루프의 카운터

따라서 향후 코드를 읽을 사람의 STM, LTM에 도움이 될만한 변수 이름을 고려하면 이름을 선택할 때 도움이 될 수 있다

이름의 품질 평가 시기

코딩하는 도중은 인지부하가 심한 상태이기에 이름에 대해 생각하고 좋은 품질의 이름을 짓는 것은 어렵다. 따라서 리뷰할때가 이름 품질 검사에 적합한 시기이다.

아래는 품질 검사 시 체크리스트로 사용할 수 있다

• 코드에 대해 아무것도 모르는 상태에서 이름이 무엇을 의미하는지 명확한가? 이름을 구성하는 단어의 의미를 알겠는가?
• 이름이 모호하거나 불명확한가?
• 혼란을 줄 수 있는 약어를 사용하는가?
• 어떤 이름들이 서로 비슷한가? 이 이름들은 서로 비슷한 것들을 가리키는가?

8.3 어떤 종류의 이름이 더 이해하기 쉬운가?

축약할 것인가? 하지 않을것인가?

호프마이스터는 연구를 통해 완전한 단어로 이루어진 식별자가, 약어나 단일 단어로 구성된 식별자보다 이해하기 쉽다는 것을 발견했다. 다만 너무 긴 변수 이름은 단점이 될 수 있다.

따라서 코드를 이해하고 버그를 쉽게 찾기 위해서라면 완전한 단어로 구성된 식별자를 사용하되, 기억을 잘하기 위해서라면 간결한 식별자를 사용해야한다. 이 둘 사이의 밸런스를 잘 잡아야한다.

로리는 식별자에 접두사나 접미사를 붙이는 규약도 충고하는데, 이러한 규약을 통해 얻는 이익보다 기억하기 어려워 발생하는 손실이 더 큰지 확인해야한다.

갈 베니아미니는 “단일문자식별자”에 대해 연구하였는데, 몇몇 경우를 제외하고는 특정 단일문자가 특정한 타입을 가진다고 이해하는데 도움이 되진 않는다. 따라서 식별자의 이름을 단어로 선택하거나 명명규약을 따르는게 더 낫다

스네이크 케이스? 캐멀 케이스?

데이브 빙클리의 연구 결과에 따르면 캐멀케이스를 사용 시 이해도가 더 높지만, 답을 찾는데 시간은 조금 더 걸린다. 하지만 대부분의 프로그래밍 교육은 캐멀케이스를 사용하고, 캐멀케이스를 통한 훈련을 받은 사람은 스네이크 케이스보다 답을 더 빨리 찾는다.

따라서 가능한 캐멀케이스를 사용하는 것이 좋지만, 이미 스네이크케이스로 작성된 코드베이스를 변경하는 것은 좋지 않다. 일관성이 중요하다

8.4 이름이 버그에 미치는 영향

버틀러는 명명 지침 위반을 탐지하는 툴을 만들고 정적버그 분석을 하였다. 결과는 잘못된 이름이 사용된 곳에 버그가 있을 확률이 크다는 유의미한 통계를 발견했다.

이는 단순히 초보 프로그래머가 잘못된 이름을 사용하거나, 복잡한 문제를 푸느라 잘못된 이름이 선택되었을 가능성이 있기에 잘못된 이름이 버그로 이어지는 것은 아닐지 모른다. 하지만 잘못된 이름이 있는 곳에 버그가 있을 확률이 크므로 잘못된 이름을 찾아서 개선하는 것은 버그 위치를 찾는데도 도움이 될 수 있다.

8.5 더 나은 이름을 선택하는 방법

이름 틀

이름 틀은 변수명을 구성하는 단어들이 결합되는 패턴을 말한다

• mex_benefit or max_benefit_per_month or benefits_per_month 등

개발자들은 서로 다른 이름들을 사용하는 경향이 있었고, 이는 같은 코드베이스 내에서도 발생할 수 있다. 하지만 같은 코드베이스에서는 같은 이름틀을 사용하는 것이 바람직하다. (작업 기억 공간과 LTM 관점에서)

따라서 각 코드베이스에서 사용할 수 있는 이름틀들을 몇가지 미리 정해놓는 것이 좋을 수 있다

더 나은 변수명 선택을 위한 페이텔슨의 3단계 모델

1. 이름에 포함할 개념을 선택한다.
   • 이름의 의도, 개체가 어떤 정보를 보유하고 있고 무엇을 위해 사용되는지
2. 각 개념을 나타낼 단어를 선택한다
   • 코드베이스에서 주로 사용되는 단어를 선택
   • 여러 단어가 경쟁적일때 선택에 어려움이 있을 수 있는데, 프로젝트에서 사용되는 단어를 모은 어휘사전이 도움이 될 수 있다
3. 이 단어들을 사용하여 이름을 구성한다
   • 이름 틀을 선택할 때는 코드베이스와 일치시키는 것이 중요하다
   • 자연어에 맞춰 이름 틀을 사용하는 것도 좋은 방법이다. (points_max보단 max_points가 자연어에 가깝다)
   • indexOf나 elementAt과 같이 전치사를 추가하는 것도 좋다