한빛출판네트워크

“컴퓨터 과학에서 어려운 것은 딱 두 가지, 캐시 무효화와 이름 짓기입니다.”

필 칼튼^{Phil Karlton}

명명(네이밍 또는 이름 짓기)^naming은 소프트웨어 개발에서 매우 중요합니다. 코드의 가독성, 이해성, 유지 보수성에 직접적인 영향을 미치기 때문에 객체, 클래스, 변수, 함수 등의 이름을 잘 선택해야 합니다. 좋은 이름은 혼동과 오류를 줄이고 다른 개발자가 코드를 더 쉽게 사용, 수정, 디버깅할 수 있도록 합니다. 컴파일러와 인터프리터에는 이름이 중요하지 않습니다. 코드 작성은 사람 중심의 활동이기에 잘못된 이름을 사용하면 혼란, 오해, 결함으로 이어질 수 있습니다. 

이름이 너무 일반적이거나 의미가 불분명하면 해당 요소의 목적과 동작을 정확히 반영하지 못할 수 있으며, 다른 개발자가 쉽게 사용하고 수정할 수 없어 오류 발생 및 시간 낭비를 초래할 수 있습니다. 클린 코드의 법칙에 맞춰 ‘의도 있는 이름'을 지으려면 어떻게 해야 할까요? 효율적인 이름 짓기에 도움이 될 몇 가지 레시피를 공유합니다.

☑️ 약어 확장하기

[문제] 모호하게 축약된 이름이 있습니다.

[해결] 충분히 길며, 모호하지 않고, 설명이 포함된 명확한 이름을 사용하세요.

[설명]  대부분의 소프트웨어 프로젝트에서 개발자는 잘못된 이름으로 인해 문제에 직면합니다. 약어로 표현된 이름은 문맥에 맞지 않고 모호합니다. 과거에는 메모리가 부족했기에 짧은 이름을 많이 사용했지만, 지금은 메모리 부족 문제가 거의 없습니다. 변수, 함수, 모듈, 패키지, 네임스페이스, 클래스 등에서 최대한 약어를 피해야 합니다. 

아래 [표준 고 언어의 명명 규칙]과 같은 섣부른 최적화는 텍스트의 가독성과 유지 관리성을 떨어뜨립니다. 

일부 언어에서는 이러한 나쁜 관행이 뿌리 깊게 박혀 있어 쉽게 변경할 수 없습니다.  자유롭게 변경할 수 있다면 아래의 [개선 코드]같이 개선할 수 있습니다.

많은 약어가 그러하듯이 fmt도 아래 그림처럼 실제 세계의 여러 가지 개념에 매핑됩니다.

컴퓨터 과학은 수학에서 탄생했습니다. 수학에서는 한 글자 변수(i, j, x, y )를 할당하는 것이 좋은 습관이죠. ‘참조’ 개념은 이 변수에서 생겨났고, 많은 사람이 수학자는 이렇게 짧은 변수를 다룰 수 있는데 컴퓨터 과학자는 왜 그럴 수 없는지 궁금해 했습니다. 수학자에게 있어 변수가 일단 수식에 입력되면, 변수는 모든 의미를 잃고 구별할 수 없게 됩니다. 그들은 많은 명명 규칙을 가지고 있으며 매우 신중하게 이름을 선정합니다. 

수학자의 차이점은 한 글자만으로도 충분히 변수를 구분할 수 있을 정도로 완전하고 공식적으로 정의된 로컬 컨텍스트^{local context} 를가지고 있다는 점입니다.

모호한 이름은 두 가지 이상의 의미를 가질 수 있습니다. 예를 들어 /usr는 user (사용자)가 아닌 universal system resource (단일 시스템 리소스)를 의미하고 /dev는 development (개발)이 아닌 device (장치)를 의미합니다. 

프로그래밍에서는 그렇지 않으므로 약어의 의미를 파악하는 데 많은 에너지를 낭비할 수 있고, 심지어는 다른 의미로 착각할 수도 있습니다. 다시 한번 말하지만, 컴파일러가 아닌 사람을 위한 소프트웨어를 작성하세요. 

☑️ 긴 이름 변경하기

[문제] 매우 길고 중복되는 이름이 있습니다.

[해결] 이름은 설명을 포함하되 너무 길지 않아야 합니다. 이름을 줄이되 사용자가 임의로 지정한 약어를 사용하지 마세요.

[설명]  긴 이름은 가독성을 저해하고 인지 부하를 늘릴 수 있습니다. 보통 MAPPER* 개념과 관련된 이름을 사용하는 것이 좋습니다. 특정 도메인에서 작업할 때, 약어(예: URL, HTTL, SSN)를 사용하는 것은 모호하지 않기 때문에 괜찮습니다.

다음은 길고 중복되는 이름입니다.

PlanetarySystem.PlanetarySystemCentralStarCatalogEntry

다음은 더 짧고 간결한 이름입니다.

PlanetarySystem.CentralStarCatalogEntry

너무 긴 이름에 대해 경고하도록 린터를 설정할 수 있습니다. 이름 길이에 대한 엄격한 규칙은 없으며 그저 휴리스틱입니다. 휴리스틱은 상황에 따라 달라진다는 점을 기억하세요.

*MAPPER (매퍼)

Model: Abstract Partial and Programmable Explaining Reality 모델은 부분적 추상화와 프로그래밍을 통해 현실을 묘사해야 함

☑️ 맞춤법 오류 수정하기

[문제] 이름에 오타 및 철자 실수가 있습니다.

[해결] 이름을 잘 관리해야 합니다. 자동 맞춤법 검사기를 사용하세요.

[설명]  가독성은 항상 중요하며 철자가 잘못되면 코드에서 용어를 검색하기가 더 어려워집니다. 다형성은 정확히 같은 이름을 가진 메서드를 기반으로 한다는 점에 유의하세요. 다음은 오타가 포함된 예제입니다.

comboFeededBySupplyer = supplyer.providers();

오타를 수정하면 다음과 같습니다.

comboFedBySupplier = supplier.providers();

몇 달 후에는 여러분이 직접 코드를 읽는 사람이 될 수 있으니 이름에 특별한 주의를 기울이세요.

☑️ 역할에 따라 인수 이름 변경하기

[문제] 선언적 이름이 아닌 메서드 인수가 있습니다.

[해결] 인수 이름을 역할에 따라 지정하세요.

[설명]  메서드를 작성할 때, 적절한 이름을 찾지 못하고 의도를 드러내는 이름을 채택하기 위해 리팩터링하는 경우가 있습니다. 다음 예제의 인수 이름을 살펴보세요. 

역할과 상황에 맞게 적용하면 이름이 명확해지는 것을 확인할 수 있습니다.

단위 테스트 프레임워크를 사용한 예제도 살펴보겠습니다. 

이 예제도 역할에 따라 인수 이름을 변경해 보았습니다.

인수 정의는 실제 사용하는 곳과 멀리 떨어져 있을 때 더 중요합니다. 이때 역할을 반영한 이름은 맥락을 명확하게 드러내므로 유용합니다.

☑️ 이름에서 불필요한 컨텍스트 제거하기

[문제] 클래스에 전역 식별자를 접두사 또는 접미사로 사용합니다.

[해결] 이름에 관련 없는 정보를 접두사나 접미사로 붙이지 마세요. MAPPER 개념을 따르기 위해 이 정보를 제거하고, 코드 검색이 수월하도록 하세요.

[설명]  클래스 접두사는 수십 년 전에 소유권을 주장하기 위해 널리 사용되던 관행이었습니다.

그러나 현재에는 깔끔하고 명확한 이름이 더 중요합니다. 여기서 말하는 불필요한 컨텍스트란 소프트웨어의 기능이나 사용성에 기여하지 않는 추가 정보나, 데이터를 코드나 사용자 인터페이스에 불필요하게 포함시키는 것을 말합니다.

다음은 불필요한 WEBB 접두사를 사용하는 예입니다.

불필요한 접두사를 제거한 코드는 다음과 같습니다.

IDE에 이름 변경 도구가 있으면 이 레시피를 쉽게 적용할 수 있습니다. 이름은 항상 상황에 맞게 지정해야 한다는 점을 기억하세요.

위 콘텐츠는 『실무로 통하는 클린 코드』에서 내용을 발췌하여 작성하였습니다.