[Clean Code] 좋은 네이밍 방법

코드에서 네이밍은 어느 상황에서나 쓰인다. 좋은 네이밍은 고민하는 시간보다 절약하는 시간이 더 많아진다.

 

오늘은 네이밍을 잘 하는 방법을 몇가지 알아보겠다.

 

 

의도를 담은 이름

변수, 함수, 클래스의 이름에는 분명한 의도를 담는게 좋다.

 

- 존재 이유

- 수행 기능

- 사용 방법

 

네이밍 규칙중에 가장 기본적인 규칙이다. 해당 이름을 통해 어떤 의도를 하려고 하는지 파악할 수 있어야 한다.

 

public List<User> a() {
        //실행 로직 ..
}

 

당연하게도 위 함수 이름으로부터는 어떤 User를 반환하는건지 알 수 없다.

 

public List<User> getActiveUsers() {
	//실행 로직 ..
}

 

네이밍에 의도를 추가하여

 

활성 사용자를 얻기 위한 목적,

사용자를 반환하는 기능,

get을 통해 조회하는 용도

임을 알 수 있다.

 

이처럼 이름에서 의도를 파악할 수 있어야 한다.

 

 

 

잘못된 정보를 담지 않기

개발자는 이름으로부터 해당 변수나 함수에 대한 힌트를 얻는다.

 

따라서 이름의 잘못된 정보는 의미를 흐리거나 혼란이나 실수를 야기할 수 있다.

 

예를 들어, 여러 객체를 담고 있는 변수가 실제 List가 아니라면 이름에 List를 포함하지 않는 것이 좋다.

 

복수형을 사용하거나 Group 등을 사용하는게 좋다.

 

또한, 한 문자 변수를 사용할 때 O, l(소문자 L)은 0, 1과 헷갈릴 수 있기 때문에 피하는게 좋다.

 

if (O == 1)
if (O == l)
if (0 == l)

 

 

 

의미 있는 구분

같은 범위 내에 같은 두 개념의 변수나 함수를 구분하기 위해 이름을 바꿀 때 좋지 않는 예시들이 있다.

 

첫 번째로, 연속적인 숫자를 덧붙인 이름을 사용하는 것이다.

 

public static void copyChars (char a1[], char a2[]) {
	//...
}

 

 

같은 char 두 변수를 구분하기 위해 연속적인 숫자 1, 2를 덧붙인 경우이다.

 

char을 복사하는 위 함수는 어디서 어느 쪽으로 복사하는지 알 수 없다.

 

public static void copyChars (char src[], char dest[]) {
	//...
}

 

source와 destination을 통해 어느 쪽으로 복사되는지 힌트를 제공할 수 있다.

 

두 번째로, 불용어를 사용하는 것이다.

 

불용어(stopwords)란 문장을 분석할 때 의미가 없는 단어들을 뜻한다.

 

예시로, Info와 Data는 의미가 불분명한 불용어이다.

 

public User getUserData() {
}

public User getUserInfo() {
}

 

두 함수의 이름으로는 어떤 차이점이 있는지 잘 알 수 없다.

 

STOP_WORDS = [
    "a", "an", "the",  # 관사: 의미를 전달하지 않음
    "it", "this", "that", "these", "those",  # 지시대명사: 모호함
    "he", "she", "they", "them",  # 인칭대명사: 특정 개체를 가리키지 않음
    "is", "are", "was", "were", "be", "been",  # 'to be' 동사: 상태를 나타내지만 구체적이지 않음
    "do", "does", "did",  # 'do' 동사: 행위를 나타내지만 구체적이지 않음
    "have", "has", "had",  # 'have' 동사: 소유를 나타내지만 구체적이지 않음
    "can", "could", "will", "would", "shall", "should",  # 조동사: 가능성이나 의지를 나타내지만 구체적이지 않음
    "and", "or", "but", "if", "then",  # 접속사: 로직을 나타내는 데 사용될 수 있지만 변수명으로는 부적절
    "in", "on", "at", "to", "for", "of", "by",  # 전치사: 관계를 나타내지만 변수명으로는 모호함
    "with", "without",  # 상태를 나타내지만 구체적이지 않음
    "very", "really", "much", "many",  # 정도를 나타내는 부사: 변수명으로 부적절
    "other", "another",  # 불특정한 다른 것을 지칭: 모호함
    "some", "any",  # 불특정 수량을 나타냄: 모호함
    "no", "not",  # 부정을 나타내지만 구체적이지 않음
    "only", "just",  # 제한을 나타내지만 구체적이지 않음
    "every", "all", "each",  # 전체를 나타내지만 구체적이지 않음
    "than", "as",  # 비교를 나타내지만 변수명으로는 부적절
    "like",  # 유사성을 나타내지만 변수명으로는 모호함
    "so", "such",  # 정도나 유형을 나타내지만 구체적이지 않음
    "too", "also",  # 추가를 나타내지만 변수명으로는 부적절
    "about", "almost",  # 근사치를 나타내지만 변수명으로는 모호함
    "even",  # 강조를 나타내지만 변수명으로는 부적절
    "here", "there",  # 위치를 나타내지만 구체적이지 않음
    "now", "then",  # 시간을 나타내지만 구체적이지 않음
    "always", "never",  # 빈도를 나타내지만 변수명으로는 부적절
    "maybe", "perhaps",  # 가능성을 나타내지만 변수명으로는 부적절
    "yes", "no",  # 긍정/부정을 나타내지만 변수명으로는 부적절
    "okay", "ok",  # 동의를 나타내지만 변수명으로는 부적절
    "well",  # 다목적으로 사용되지만 변수명으로는 모호함
    "let", "make",  # 행위를 나타내지만 구체적이지 않음
    "thing", "stuff",  # 매우 일반적인 명사: 구체성 부족
    "way", "manner",  # 방식을 나타내지만 구체적이지 않음
    "kind", "type",  # 유형을 나타내지만 구체적이지 않음
    "part", "piece",  # 부분을 나타내지만 구체적이지 않음
    "example", "instance",  # 예시를 나타내지만 변수명으로는 부적절
    "case", "situation",  # 상황을 나타내지만 구체적이지 않음
    "result", "outcome",  # 결과를 나타내지만 구체적이지 않음
    "data", "information",  # 데이터를 나타내지만 너무 일반적임
    "value", "amount",  # 값을 나타내지만 구체적이지 않음
    "number", "quantity",  # 수량을 나타내지만 구체적이지 않음
    "item", "element",  # 요소를 나타내지만 구체적이지 않음
    "object", "entity",  # 객체를 나타내지만 너무 일반적임
    "flag", "indicator",  # 표시를 나타내지만 구체적이지 않음
    "temp", "tmp",  # 임시를 나타내는 약어: 구체성 부족
    "misc", "etc",  # 기타를 나타내는 약어: 모호함
]

 

변수명에 들어가면 좋지 않은 불용어들을 예시로 뽑아보았다.

 

 

발음하기 쉬운 이름

결국 코드는 사람이 읽고, 사람이 리뷰하게 된다.

 

읽기 쉬운 좋은 코드에는 발음하기 좋은 이름 또한 한 도움이 될 수 있겠다.

 

java.time 패키지에는 LocalDate 라는 yyyy-mm-dd 형식의 클래스가 있다.

 

getymd() 보다는 getLocalDate()가 더 좋은 예시가 되겠다.

 

 

 

검색하기 쉬운 이름

프로젝트의 규모가 커지다보면, 상수나 함수가 어떤 클래스에 정의되어 있는지 찾을 수 없을 때가 있다.

 

실제로 나는 팀원이 개발한 코드에서 어떤 함수를 찾기 위해 IntelliJ에서 shift를 두 번 누르면 나오는 검색 창에 검색하여 함수를 찾은 적이 있다.

 

for문이나 단순한 작업을 하는 함수에서는 i, j, k와 같은 단순한 변수명을 사용할 수 있겠지만, 아닌 경우라면 

 

보통 짧은 변수명 보다는 긴 변수명이 좋고, 이름의 길이는 범위 크기에 비례해야 한다.

 

 

 

개인의 기억력에 의존하지 않는 이름

가끔 코드를 작성한 사람이 기억할 수 있는 정보를 통해 이해할 수 있는 변수명을 본 적이 있다.

 

처음 보는 사람도 이해할 수 있는 이름을 사용하고, 최대한 명료하게 작명해야 한다.

 

 

클래스 이름

클래스 이름은 명사나 명사구가 적합하다.

 

DataBaseConnection은 좋고, ConnectToDatabase는 좋지 않다.

PaymentProcessor는 좋고, ProcessPayments는 좋지 않다.

EmailSender는 좋고, SendEmails는 좋지 않다.

Order은 좋고, MangeOrders는 좋지 않다.

 

 

메서드 이름

반대로 메서드 이름은 동사나 동사구가 적합하다.

 

createUser()은 좋고, user()은 좋지 않다.

saveFile()은 좋고, fileSave()는 좋지 않다.

searchProducts()는 좋고, productSearch는 좋지 않다.

addToCart는 좋고, cartAddition은 좋지않다.

 

 

한 개념에 한 단어

추상적인 개념 하나에 단어 하나를 선택해 사용하는 것이 좋다.

 

여러 개발자가 프로젝트를 시작하기 전에, 프로젝트 컨벤션을 정하고 시작하는 것과 비슷한 이유이다.

 

예를 들어서, 정보를 가져오는 함수는 getXXX()를 사용하기로 약속하는 것이다.

 

이처럼 프로젝트는 일관성 있는 어휘를 사용한 이름으로 구성되어야 한다.

 

 

해법 영역에서 가져온 이름

코드를 보게 되는 사람은 개발자일 것이다. 그러므로 전산 용어, 알고리즘, 패턴, 수학 용어 등을 사용해도 좋다.

 

Visitor 패턴을 이용한 AccountVisitor, Queue자료구조를 이용한 JobQueue 이름은 모두 괜찮다. 

 

개발자에게 익숙한 기술 개념을 사용한 이름은 적합한 선택이다.

 

 

---

 

오늘은 개발자에게 굉장히 익숙한 주제인 네이밍을 다루어 보았다.

 

평소 이름을 좋은 코드를 많이 보았던 기억으로 감을 통해 지었었다.

 

카카오 로그인 프로젝트에 클래스 이름을 KakaoInfo로 지었던 나를 반성했다 😅

 

출처
Clean Code: A Handbook of Agile Software Craftsmanship 
by Robert C. Martin