8. 명명을 잘하는 방법

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

8.1 이름이 중요한 이유

• 실제로 많은 프로그래머는 이름에 짓는 것에 어려움을 겪습니다.
• 이름을 짓는 것은 어렵지만, 코드에서 우리가 추론하는 객체에 맞는 이름을 고르는 것은 중요합니다.

8.1.1 명명이 중요한 경우

• 식별자 이름이 중요한 이유는 크게 네 가지 입니다.

이름은 코드 베이스의 상당 부분을 차지한다.

코드 리뷰 시 이름의 역할

이름은 문서화의 가장 쉬운 형태

이름이 표식 역할을 할 수 있음

8.1.2 명명에 대한 다양한 관점

• 좋은 이름에 대한 명명법 연구자들이 가지고 있는 세가지 관점이 있습니다.

좋은 이름은 문법적으로 정의할 수 있다

이름	설명	바람직하지 않은 이름의 예
비정상적인 대문자 사용	식별자는 대문자를 올바르게 사용해야 한다	paGecoUnter
연속된 두개의 밑줄	식별자는 연속된 여러 개의 밑줄을 가져서는 안된다	page__counter
사전 등재 단어	식별자는 단어로 만들어야 하고 약어는 원래의 명싱보다 더 자주 사용될 경우에만 사용해야한다	page_countr
단어의 수	식별자에 사용되는 단어는 두 개에서 네 개 사이여야한다	page_counter_converted_and_normalized_value
너무 많은 단어	식별자에 사용되는 단어는 네 개를 초과하면 안된다	(위와 동일)
짧은 이름	식별자의 길이는 c, d, e, g, i, in ...의 특정 이름을 제외하고 8글자보다 작으면 안된다	P, page
열거형 식별자 선언 순서	분명한 이유가 없다면, 열거형은 알파벳 순서로 선언	CareValue = {ACE, EIGHT, FIVE, FOUR}
외부 밑줄	식별자는 밑줄로 시작하거나 끝나서는 안된다	__page_counter_
식별자 인코딩	헝가리언 표기법 등으로 식별자 이름에 타입 정보를 나타내면 안된다	int_page_counter
긴 이름	긴 식별자 이름은 가능한 피해야 한다	page_counter_converted_and_normalized_value
명명법 규약 이상	식별자는 대문자와 소문자를 표준적이지 않은 방법으로 섞어서 사용하면 안된다	Page_counter
숫자를 나타내는 식별자 이름	식별자는 숫자만을 나타내는 단어나 수를 사용하면 안된다	FIFTY

이름은 코드베이스 내에서 일관성이 있어야 한다

• 좋은 이름에 대한 또 다른 관점은 일관성입니다.
• 좋은 명명 방식의 가장 중요한 측면은 코드베이스 전반에 걸쳐 비슷하게 명명하는 것입니다.

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

• 최신 코드는 명명 지침을 더 잘 따릅니다.
• 동일한 코드베이스 내에서 명명 관행은 일정하게 유지됩니다.
• 명명 관행 면에서 작은 코드베이스와 큰 코드베이스 사이에 차이는 없습니다.

정리를 하면 명명 규약에 대한 두 가지 관점은 다음과 같습니다.

연구자	관점
버틀러	문법적으로 유사한 이름
알라마니스	코드베이스 내에서의 일관성

• 코드를 읽는 사람에 따라 좋은 이름도 달라집니다.

8.2 명명의 인지적 측면

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

• 명명과 인지 사이의 연결점은 다음과 같습니다.

연구자	관점	인지적으로 맞는 이유
버틀러	문법적으로 비슷한 이름	이름을 처리할 때 인지 부하가 낮음
알라마니스	코드베이스 내에서의 일관성	청킹을 지원

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

• 변수 이름을 처리할 때 작업 기억 공간에 정보를 제공하는 것은 STM뿐만이 아니라 LTM도 관련이 있습니다.
• 변수 이름 또는 클래스에 올바른 도메인 개념을 사용하면 코드의 독자가 LTM에서 관련 정보를 찾는 데 도움이 될 수 있습니다.

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

• 식별자 이름에 세 가지 유형의 지식을 표현할 수 있습니다.
  1. 코드의 도메인에 대해 생각할 때 이름이 도움이 됩니다.
  2. 프로그래밍에 대해 생각할 때도 이름이 도움이 됩니다.
  3. 경우에 따라 변수에 LTM이 이미 알고 있는 규약에 대한 정보가 포함할 수 있습니다.

8.2.4 이름의 품질 평가 시기

• 코드 중에 좋은 품질의 이름은 어렵습니다.
• 코드 리뷰는 식별자 이름의 품질을 검토하기 좋은 기회입니다.

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

8.3.1 축약할 것인가, 하지 않을 것인가

• 완전한 단어를 사용하는 것이 합리적이지만 좀 더 참고할 사항이 있습니다.
• 문자와 약어는 종종 읽을 때 차이가 없습니다.
• 단어 식별자를 사용할 때. 변수 이름이 길수록 기억하기 어렵고 많은 시간이 걸립니다.
• 즉, 코드를 이해하고 버그를 쉽게 찾기 위해서라면 명확한 의미의 단어를 사용해야 하는 반면, 기억을 잘하기 위해서라면 간결한 약자를 사용해야 합니다.
• 좋은 변수 이름을 명명하기 위해서는 이 둘 사이의 주의 깊은 균형이 필요합니다.

식별자를 접두자 또는 접미사로 묶는 명명규약도 조심해야 합니다.

단일 문자가 변수로 흔히 사용됩니다.

• 프로그래밍 언어마다 단일 문자 변수 이름을 사용하는 규칙이 다릅니다.
• 단일 문자 변수 이름과 데이터 타입의 연관성에 대한 결과는 다른 사람에 대해 우리가 어떤 가정을 할 때 그것을 당연한 것으로 여길 수 없다는 것을 상기합니다.

8.3.2 스네이크 케이스냐, 캐멀 케이스냐?

• 프로그래밍 언어에는 변수 이름에 대한 스타일 가이드가 있지만 그 지침이 동일하지는 않습니다.
• 하나의 식별자로 교육을 더 많이 받은 사람이 그 스타일에 강점이 생기나 다른 스타일을 쓸 때 부정적 영향을 받습니다.
• 다만, 위의 이유로 바꾸는 것보다는 일관성이 더 중요합니다.

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

• 좋지 못한 명명 규약은 버그 발생에 직접적인 영향을 미칠 수 있습니다.

8.4.1 나쁜 이름을 가진 코드에 버그가 더 많다

• 잘못된 명명 방식은 단지 읽고 이해하기 유지보수하기 어려운 코드가 아니라 잘못된 코드일 가능성이 높습니다.
• 잘못된 이름 문제를 해결하는 것이 반드시 버그를 고치거나 예방하지는 않지만, 코드베이스를 검사하여 잘못된 이름이 발생하는 위치를 찾아내는 일은 코드를 개선하고 버그 발생 가능성이 있는 위치를 찾는데 도움이 될 수 있습니다.

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

8.5.1 이름 틀

• 이름 틀은 변수 이름의 요소가 일반적으로 결합되는 패턴입니다.
• 수많은 다른 이름은 대부분 개발자가 다른 이름틀을 사용했기 때문입니다.
• 코드베이스 내에서 서로 다른 이름 틀을 사용하는 것은 바람직하지 않습니다.
  • 첫째, 인지 부하 측면에서 관련된 개념을 변수 이름 내에서 그리고 변수 이름내 다른 위치에서 찾는 것은 불필요한 외부 인지 부하를 유발합니다.
  • 둘째, 변수 이름이 비슷한 경우 동일한 이름 틀을 사용하면 LTM이 관련 정보를 더 쉽게 찾을 수 있습니다.
• 유사한 이름 틀을 사용하면 작업 기억 공간과 LTM에 큰 도움이 되기 때문에 각 코드베이스에서 사용할 수 있는 여러 가지 이름 틀을 미리 정해놓는 것이 좋습니다.

8.5.2 더 나은 변수명에 대한 페이텔슨의 3단계 모델

• 개발자들이 더 나은 이름을 선택하는 것이 도움이 되도록 3단계 모델을 설계하는 것이 좋습니다.
  1. 이름에 포함할 개념을 선택합니다.
  2. 각 개념을 나타낼 단어를 선택합니다.
  3. 이 단어들을 사용하여 이름을 구성합니다.

3단계 모델의 세부 사항

• 첫 번째 단계에서는 이름을 통해 나타낼 개념을 선택하는데, 개념은 도메인별로 아주 다르며 어떤 차원을 포함할 것인지 결정하는 것이 가장 중요할 수도 있습니다.
• 두 번째 단계는 각 개념을 나타낼 단어를 선택하는 것입니다.
  • 프로젝트 어휘 사전이 있으면 프로그래머가 일관된 이름을 선택하는데 도움이 될 수 있습니다.
• 세 번째 단계는 선택한 단어를 사용하여 이름을 구성하는 것으로, 이름 지정 틀 중 하나를 선택하는 것에 해당됩니다.
• 반드시 이러한 단계가 순서대로 진행될 필요는 없습니다.

요약

• 캐멀 케이스 같은 문법 규칙부터 코드베이스 내의 일관성까지, 좋은 이름에 대한 다양한 관점이 있습니다.
• 다른 차이가 없다면 스네이크 케이스로 작성된 변수보다 캐멀 케이스 변수가 기억하기 쉽습니다. 하지만 사람들은 스네이크 케이스를 더 빨리 식별합니다.
• 잘못된 이름이 있는 코드에서 버그가 발생할 가능성이 높습니다. 다만 이 둘 사이에 반드시 인과관계가 있는 것은 아닙니다.
• 다양한 형식의 변수명을 만드는 데 사용할 수 있는 이름 틀이 많이 있으므로, 틀의 수를 줄이면 코드를 이해하는데 도움이 많이 됩니다.
• 페이텔슨의 3단계 모델(이름에 사용할 개념, 해당 개념에 사용할 정의. 결합 방법)을 적용하면 고품질의 이름을 만들 수 있습니다.