아이템[68]. 일반적으로 통용되는 명명 규칙을 따르라

자바 플랫폼은 명명 규칙이 잘 정립되어 있으며, 그 중 많은 것이 자바 언어 명세에 기술되어 있습니다.

자바의 명명 규칙은 크게 철자와 문법, 두 범주로 나뉩니다.

철자 규칙은 패키지, 클래스, 인터페이스, 메서드, 필드, 타입 변수의 이름을 다룹니다.

이 규칙들은 특별한 이유가 없는 한 반드시 따라야 합니다.

이 규칙을 어긴 API는 사용하기 어렵고, 유지보수하기 어렵습니다.

철자 규칙이나 문법 규칙을 어기면 달느 프로그래머들이 그 코드를 읽기 번거로울 뿐 아니라 다른 뜻으로 오해할 수도 있고 그로 인해 오류까지 발생할 수 있습니다.

패키지, 모듈 명명 규칙

패키지와 모듈 이름은 각 요소를 점(.)으로 구분하여 계층적으로 짓습니다.

요소들은 모두 소문자 알파벳 혹은 (드물게) 숫자로 이뤄집니다.

여러분 조직 바깥에서도 사용될 패키지라면 조직의 인터넷 도메인 이름을 역순으로 사용합니다.

예컨대 edu.cmu, com.google, org.eff 식입니다.

예외적으로 표준 라이브러리와 선택적 패키지들은 각각 java와 javax로 시작합니다.

도메인 이름을 패키지 이름의 접두어로 변환하는 자세한 규칙은 자바 언어 명세에 적혀 있습니다.

패키지 이름의 나머지는 해당 패키지를 설명하는 하나 이상의 요소로 이뤄집니다.

각 요소는 일반적으로 8자 이하의 짧은 단어로 합니다.

utilities보다는 util처럼 의미가 통하는 약어로 추천합니다.

여러 단어로 구성된 이름이라면 awt처럼 각 단어의 첫 글자만 따서 써도 좋습니다.

요소의 이름은 한 단어 혹은 약어로 이뤄집니다.

인터넷 도메인 이름 뒤에 요소 하나만 붙인 패키지가 많지만, 많은 기능을 제공하는 경우엔 계층을 나눠 더 많은 요소로 구성해도 좋습니다.

예를 들어 java.util은 java.util.cocurrent.atomic과 같이 그 밑에 수많은 패키지를 가지고 있습니다.

자바가 패키지 계층에 관해 언어 차원에서 지원하는 건 거의 없지만, 어쨌든 이처럼 하부의 패키지를 하위 패키지라 부릅니다.

클래스, 인터페이스 명명 규칙

(열거 타입과 애너테이션을 포함해) 클래스와 인터페이스의 이름은 하나 이상의 단어로 이뤄지며, 각 단어는 대문자로 시작합니다.

여러 단어의 첫 글자만 딴 약자나 max, min처럼 널리 통용되는 줄임말을 제외하고는 단어를 줄여 쓰지 않도록 합니다.

약자의 경우 첫 글자만 대문자로 할지 전체를 대문자로 할지는 살짝 논란이 있습니다.

전체를 대문자로 쓰는 프로그래머도 있지만, 그래도 첫 글자만 대문자로 하는 쪽이 훨씬 많습니다.

HttpUrl처럼 여러 약자가 혼합된 경우라도 각 약자의 시작과 끝을 명확히 알 수 있기 때문입니다.

메서드, 필드 명명 규칙

메서드와 필드 이름은 첫 글자를 소문자로 쓴다는 점만 빼면 클래스 명명 규칙과 동일합니다.

첫 단어가 약자라면 단어 전체가 소문자여야 합니다.

단 '상수 필드'는 예외입니다.

상수 필드를 구성하는 단어는 모두 대문자로 쓰며 단어 사이는 밑줄로 구분합니다.

상수 필드는 값이 불변인 static final 필드를 말합니다.

달리 말하면 static final 필드의 타입이 기본 타입이나 불변 참조 타입(아이템 17)이라면 상수 필드에 해당합니다.

static final 필드이면서 가리키는 객체가 불변이라면 비록 그 타입은 가변이더라도 상수 필드입니다.

이름에 밑줄을 사용하는 요소로는 상수 필드가 유일하다는 사실도 기억해둡시다.

지역변수 명명 규칙

지역변수에도 다른 멤버와 비슷한 명명 규칙이 적용됩니다.

단, 약어를 써도 좋습니다.

약어를 써도 그 변수가 사용되는 문맥에서 의미를 쉽게 유추할 수 있기 때문입니다.

입력 매개변수도 지역변수의 하나입니다.

하지만 메서드 설명 문서에까지 등장하는 만큼 일반 지역변수보다는 신경을 써야 합니다.

타입 매개변수 명명 규칙

타입 매개변수 이름은 보통 한 문자로 표현합니다.

대부분은 다음의 다섯 가지 중 하나입니다.

• T : 임의의 타입
• E : 컬렉션 원소의 타입
• K와 V : 맵의 키와 값
• X : 예외
• R : 메서드의 반환 타입

그 외에 임의 타입의 시퀀스에는 T, U, V 혹은 T1, T2, T3를 사용합니다.

문법 규칙은 철자 규칙과 비교하면 더 유연하고 논란도 많습니다.

패키지에 대한 규칙은 따로 없습니다.

클래스의 문법 규칙

객체를 생성할 수 있는 클래스의 이름은 보통 단수 명사나 명사구를 사용합니다.

(Thread, PriorityQueue, ChessPiece 등)

객체를 생성할 수 없는 클래스(아이템 4)의 이름은 보통 복수형 명사로 짓습니다.

(Collectors, Collections 등)

인터페이스의 문법 규칙

인터페이스의 이름은 클래스와 똑같이 짓거나 able 혹은 ible로 끝나는 형용사로 짓습니다.

(Runnable, Iterable, Comparator)

애너테이션의 문법 규칙

애너테이션은 워낙 다양하게 활용되어 지배적인 규칙이 없이 명사, 동사, 전치사, 형용사가 두루 쓰입니다.

(BindingAnnotation, Inject, ImplementBy, Singleton)

메서드의 문법 규칙

어떤 동작을 수행하는 메서드의 이름은 동사나 (목적어를 포함한) 동사구로 짓습니다.

(append, drawImage)

boolean 값을 반환하는 메서드라면 보통 is나 (드물게) has로 시작하고 명사나 명사구 혹은 형용사로 기능하는 아무 단어나 구로 끝나도록 짓습니다.

(isDigit, isProbablePrime, isEmpty, isEnabled, hasSiblings)

반환 타입이 boolean이 아니거나 해당 인스턴스의 속성을 반환하는 메서드의 이름은 보통 명사, 명사구, 혹은 get으로 시작하는 동사구로 짓습니다.

(size, hashCode, getTime)

세 번째 형식, 즉 get으로 시작하는 형태만 써야 한다는 주장도 있지만, 근거가 빈약하다고 합니다.

get으로 시작하는 형태는 주로 자바빈즈(JavaBeans) 명세에 뿌리를 두고 있습니다.

자바빈즈는 재사용을 위한 컴포넌트 아키텍처의 초기 버전 중 하나로, 최근의 도구 중에도 이 명명 규칙을 따르는 경우가 제법 많습니다.

따라서 이런 도구와 어우러지는 코드를 작성한다면 이 규칙을 따라도 상관없습니다.

한편 클래스가 한 속성의 게터와 세터를 모두 제공할 때도 적합한 규칙입니다.

일너 경우라면 보통 getAttribute와 setAttribute 형태의 이름을 갖게 될 것입니다.

꼭 언급해둬야 할 특별한 메서드 이름이 몇 가지 있습니다.

객체의 타입을 바꿔서, 다른 타입의 또 다른 객체를 반환하는 인스턴스 메서드의 이름은 보통 toType 형태로 짓습니다. (toString, toArray)

객체의 내용을 다른 뷰로 보여주는 메서드(아이템 6)의 이름은 asType 형태로 짓습니다. (asList)

객체의 값을 기본 타입 값으로 반환하는 메서드의 이름은 보통 typeValue 형태로 짓습니다. (intValue)

정적 팩터리의 이름은 다양하지만 from, of, valueOf, instance, getInstance, newInstance을 흔히 사용합니다.

필드의 문법 규칙

필드 이름에 관한 문법 규칙은 클래스, 인터페이스, 메서드 이름에 비해 덜 명확하고 덜 중요합니다.

API 설계를 잘 했다면 필드가 직접 노출될 일이 거의 없기 때문입니다.

boolean 타입의 필드 이름은 보통 boolean 접근자 메서드에서 앞 단어를 뺀 형태입니다.

(initialized, composite)

다른 타입의 필드라면 명사나 명사구를 사용합니다.

(height, digits, bodyStyle)

지역변수 이름도 필드와 비슷하게 지으면 되나, 조금 더 느슨합니다.

정리

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