[Effective Java] item 68. 일반적으로 통용되는 명명 규칙을 따르라

[Effective Java] item 68. 일반적으로 통용되는 명명 규칙을 따르라

자바 플랫폼은 명명 규칙이 잘 정립되어 있으며, 그중 많은 것이 자바 언어 명세에 기술되어 있다. 자바의 명명 규칙은 크게 철자와 문법, 두 범주로 나뉜다.

철자 규칙

• 패키지, 클래스, 인터페이스, 메서드, 필드, 타입 변수의 이름을 다룬다.
• 이 규칙들은 특별한 이유가 없는 한 반드시 따라야 한다. 이 규칙을 어긴 API는 사용하기 어렵고, 유지보수하기 어렵다. 철자 규칙이나 문법 규칙을 어기면 다른 프로그래머들이 코드를 읽기 번거로울 뿐만 아니라 다른 뜻으로 오해할 수도 있고 그로 인해 오류까지 발생할 수 있다.

패키지와 모듈 이름

• 패키지와 모듈 이름은 각 요소를 점(.)으로 구분하여 계층적으로 짓는다.
• 요소들은 모두 소문자 알파벳 혹은 (드물게) 숫자로 이뤄진다.
• 조직 바깥에서도 사용될 패키지라면 조직의 인터넷 도메인 이름을 역순으로 사용한다. (예) edu.cmu, com.google, org.eff 등.
• 패키지 이름의 나머지는 해당 패키지를 설명하는 하나 이상의 요소로 이뤄진다. 각 요소는 일반적으로 8자 이하의 짧은 단어로 한다. (utilities보다는 util처럼 의미가 통하는 약어를 추천한다).
• 여러 단어로 구성된 이름이라면 awt처럼 각 단어의 첫 글자만 따서 써도 좋다. 요소의 이름은 보통 한 단어 혹은 약어로 이루어진다.
• 인터넷 도메인 이름 뒤에 요소 하나만 붙인 패키지가 많지만, 많은 기능을 제공하는 경우엔 계층을 나눠 더 많은 요소로 구성해도 좋다.
• 자바가 패키지 계층에 대해 언어 차원에서 지원하는 건 거의 없지만, 이처럼 하부의 패키지를 하위 패키지(subpackage)라 부른다.

클래스와 인터페이스 이름

• (열거 타입과 애너테이션을 포함해) 클래스와 인터페이스의 이름은 하나 이상의 단어로 이뤄지며, 각 단어는 대문자로 시작한다(List, FutherTask 등).
• 여러 단어의 첫 글자만 딴 약자나 max, min처럼 널리 통용되는 줄임말을 제외하고는 단어를 줄여 쓰지 않도록 한다.
• 약자의 경우 첫 글자만 대문자로 할지 전체를 대문자로 할지는 살짝 논란이 있었다. 전체를 대문자로 쓰는 프로그래머도 있지만 그래도 첫 글자만 대문자로 하는 쪽이 훨씬 많다. HttpUrl처럼 여러 약자가 혼합된 경우라도 각 약자의 시작과 끝을 명확히 알 수 있기 때문이다.

메서드와 필드 이름

• 메서드와 필드 이름은 첫 글자를 소문자로 쓴다는 점만 빼면 클래스 명명 규칙과 같다(remove, ensureCapacity 등).
• 첫 단어가 약자라면 단어 전체가 소문자여야 한다

상수 필드

• 구성하는 단어 모두 대문자로 쓰며 단어 사이는 밑줄로 구분한다(VALUES, NEGATIVE_INFINITY 등). (값이 불변인 static final 필드)

지역변수

• 지역변수에도 다른 멤버와 비슷한 명명 규칙이 적용된다. 단, 약어를 써도 좋다. 약어를 써도 그 변수가 사용되는 문맥에서 의미를 쉽게 유추할 수 잇기 때문이다(i, denom, houseNum 등)

타입 매개변수

• 보통 한 문자로 표현한다. 대부분은 다음의 다섯 가지 중 하나다.
  • T: 임의의 타입
  • E: 컬렉션 원소의 타입
  • K, V: 맵의 키와 값
  • X: 예외
  • R: 메서드의 반환 타입
  • T, U, V or T1, T2, T3: 임의 타입의 시퀀스

철자 규칙 정리

식별자 타입	예
패키지와 모듈	org.junit.jupiter.api, com.google.common.collect
클래스와 인터페이스	Stream, FutureTask, LinkedHashMap, HttpClient
메서드와 필드	remove, groupingBy, getCrc
상수 필드	MIN_VALUE, NEGATIVE_INFINITY
지역 변수	i, denom, houseNum
타입 매개변수	T, E, K, V, X, R, U, V, T1, T2

문법 규칙

클래스

• 객체를 생성할 수 있는 클래스(열거 타입 포함)의 이름은 보통 단수 명사나 명사구를 사용한다(Thread, PriorityQueue, ChessPiece 등).
• 객체를 생성할 수 없는 클래스(아이템 4)의 이름은 보통 복수형 명사로 짓는다(Collectors, Collections 등)

인터페이스

• 인터페이스의 이름은 클래스와 똑같이 짓거나(Collection, Comparator 등), able 혹은 ible로 끝나는 형용사로 짓는다(Runnable, Iterable, Accessible).

애너테이션

• 애너테이션은 워낙 다양하게 활용되어 지배적인 규칙이 없어 명사, 동사, 전치사, 형용사가 두루 쓰인다(BindingAnnotation, Inject, ImplementedBy, Singleton 등).

메서드

동작을 수행하는 경우

• 동사나 (목적어를 포함한) 동사구로 짓는다(append, drawImage).

  boolean 값을 반환하는 경우

• 보통 is나 (드물게) has로 시작하고 명사나 명사구, 혹은 형용사로 기능하는 아무 단어나 구로 끝나도록 짓는다(isDigit, isProbablePrime, isEmpty, isEnabled, hasSiblings 등).

  인스턴스의 속성을 반환하는 경우

• 보통 명사, 명사구, 혹은 get으로 시작하는 동사구로 짓는다(size, hashCode, gettime 등).
• 세 번째 형식, 즉 get으로 시작하는 형태만 써야 한다는 주장도 있지만 근거가 빈약하다. 다음 코드에서 보듯 보통은 처음 두 형태를 사용한 코드의 가독성이 더 좋기 때문이다.

    if (car.speed() > 2 * SPEED_LIMIT)
        generateAudibleAlert("경찰 조심하세요!");

• get으로 시작하는 형태는 주로 자바빈즈(JavaBeans) 명세에 뿌리를 두고 있다. 자바빈즈는 재사용을 위한 컴포넌트 아키텍처의 초기 버전 중 하나로, 최근의 도구 중에서도 이 명명 규칙을 따르는 경우가 제법 많다. 따라서 이런 도구와 어우러지는 코드를 작성한다면 이 규칙을 따라도 상관 없다.
• 한편 클래스가 한 속성의 게터와 세터를 모두 제공할 때도 적합한 규칙이다. 이런 경우라면 보통 getAttribute와 setAttribute 형태의 이름을 갖게 될 것이다.

객체의 타입을 바꿔서 다른 타입의 또 다른 객체를 반환하는 메서드

• toType 형태(toString, toArray 등)로 짓는다.

객체의 내용을 다른 뷰로 보여주는 메서드

• asType(asList 등)로 짓는다.

객체의 값을 기본 타입으로 반환하는 메서드의 이름

• typeValue 형태로 짓는다(intValue 등)

정적 팩터리의 이름

• from, of, valueOf, instance, getInstance, newInstance, getType, newType을 흔히 사용한다. (아이템 1)

필드 이름

• API 설계를 잘 했다면 필드가 직접 노출되는 일이 거의 없기 때문에 클래스, 인터페이스, 메서드 이름에 비해 덜 명확하고 덜 중요하다.

boolean 타입의 필드 이름

• 보통 boolean 접근자 메서드에서 앞 단어를 뺀 형태다(initialized, composite 등).

다른 타입의 필드

• 명사나 명사구를 사용한다(height, digits, bodyStyle 등).

지역 변수 이름

• 필드와 비슷하게 지으면 되나, 조금 더 느슨하다.

핵심정리

• 표준 명명 규칙을 체화하여 자연스럽게 베어 나오도록 하자.
• 철자 규칙은 직관적이라 모호한 부분이 적은 데 반해, 문법 규칙은 더 복잡하고 느슨하다.
• 자바 언어 명세의 말을 인용하자면 "오랫동안 따라온 규칙과 충돌한다면 그 규칙을 맹종해서는 안된다." 상식이 이끄는 대로 따르자.

참고 자료

• Effective Java 3/E