Merge pull request #335 from SujinEmilyCho/week10_sujin

[#68][2기] 일반적으로 통용되는 명명 규칙을 따르라

9장/68_일반적으로_통용되는_명명_규칙을_따르라_조수진.md

@@ -0,0 +1,80 @@
+# 아이템 68. 일반적으로 통용되는 명명 규칙을 따르라
+
+### 철자 규칙 - 반드시 따라야 한다
+
+1. 패키지
+    - 각 요소를 점(.)으로 구분하여 계층적으로 짓는다
+    - 모든 요소들은 모두 소문자 알파벳 혹은 (드물게) 숫자로 이뤄진다
+    - 조직 밖에서도 사용될 패키지라면 조직의 인터넷 도메인 이름을 역순으로 사용한다
+        ex edu.cmu, com.google, org.eff
+    - 표준 라이브러리와 선택적 패키지들은 예외적으로 java, javax로 시작
+    - 패키지의 나머지 부분은 8자 이하의 짧은 단어, 하나 이상의 요소로 이뤄진다
+    - utilities보다 util처럼 의미가 통하는 약어를 추천, 약어(ex. awt)도 가능
+    - 많은 기능을 제공하는 경우에는 계층을 나눠서 더 많은 요소로 구성해도 좋다(하위 패키지)
+        ex. java.util.concurrent.atomic
+2. 클래스, 인터페이스(열거 타입, 애너테이션 포함)
+    - 하나 이상의 단어로 이뤄지며, 각 단어는 대문자로 시작(ex. List, FutherTask 등)
+    - 여러 단어의 첫 글자만 딴 약어나 max, min처럼 널리 통용되는 줄임말을 제외하고 단어를 줄여쓰지 않는다
+    - 약자의 경우 첫 글자만 대문자로 쓰거나 모두 대문자로 쓸 수 있는데, 가독성과 단어 의미 구분을 위해 첫 글자만 대문자로 하는 쪽이 많다(HttpUrl vs HTTPURL)
+3. 메서드, 필드
+    - 첫 글자를 소문자로 쓴다는 점만 빼면 클래스 명명 규칙과 같다 (ex. remove, ensureCapacity 등)
+    - 단, 첫 단어가 약어라면 그 단어 전체가 소문자여야 한다
+4. 상수 필드(= static final 필드)
+    - 모든 단어를 대문자로 쓰며 단어 사이에는 밑줄로 구분한다 (ex. VALUES, NEGATIVE_INFINITY 등)
+    - 이름에 밑줄을 사용하는 요소는 상수 필드가 유일
+5. 지역 변수
+    - 다른 멤버와 비슷
+    - 약어를 써도 좋다 (ex. i, denom, houseNum 등)
+    - 입력 매개변수는 조금 더 신경써서 지을 것
+6. 타입 매개변수
+    - 보통 한 문자로 표현
+    - 컬렉션 원소 타입 E, 맵의 키와 값은 K, V, 예외는 X, 메서드의 반환 타입은 R
+    - 그 외의 임의 타입 T, U, V 혹은 T1, T2, T3
+
+### 문법 규칙 - 유연하다
+
+1. 패키지
+    - 규칙 없음
+2. 객체를 생성할 수 있는 클래스(열거 타입 포함)
+    - 보통 단수 명사나 명사구를 사용한다 (ex. Thread, PriorityQueue, ChessPiece 등)
+3. 객체를 생성할 수 없는 클래스
+    - 보통 복수형 명사로 짓는다 (ex. Collectors, Collections 등)
+4. 인터페이스
+    - 클래스와 똑같이 짓거나 able, ible로 끝나는 형용사로 짓는다 (ex. Collection, Comparator, Runnable, Iterable, Accessible)
+5. 애너테이션
+    - 지배젹인 규칙 없이 명사, 동사, 전치사, 형용사 두루 쓰인다 (ex. BindingAnnotation, Inject, ImplementedBy, Singleton 등)
+6. 동작을 수행하는 메서드
+    - 동사나 (목적어를 포함한) 동사구로 짓는다 (ex. append, drawImage)
+7. boolean 값을 반환하는 메서드
+    - is나 (드물게) has로 시작하고 명사, 명사구, 형용사로 기능하는 단어나 구로 끝나도록 짓는다 (ex. isDigit, isProbablePrime, isEmpty, isEnabled, hasSiblings 등)
+8. 반환 타입이 boolean이 아니거나, 인스턴스의 속성을 반환하는 메서드
+    - 명사, 명사구, 혹은 get으로 시작하는 동사구 (ex. size, hashCode, getTime 등)
+    - get으로 시작하는 형태는 자바빈즈 명세에 뿌리를 드고 있다. 이런 도구와 어우러지는 코드를 작성한다면 이 규칙을 따라도 좋다.
+9. 객체의 타입을 바꿔서 반환하는 인스턴스 메서드
+    - toType (ex. toString, toArray 등)
+10. 객체의 내용을 다른 뷰로 보여주는 메서드
+    - asType (ex. asList 등)
+11. 객체의 값을 기본 타입 값으로 반환하는 메서드
+    - typeValue (ex. intValue 등)
+12. 정적 팩터리 메서드
+    - from
+    - of
+    - valueOf
+    - instance
+    - getInstance
+    - newInstance
+    - getType
+    - newType
+13. 필드 이름
+    - 클래스, 인터페이스, 메서드 이름에 비해 덜 명확하고 덜 중요
+    - API 설계를 잘 했다면 필드가 직접 노출될 일이 거의 없기 때문
+    - boolean 타입은 접근자에서 is, has를 제외한 형태(ex. initialized, composite 등)
+    - 다른 타입 필드라면 명사나 명사구 (ex. geight, digits, bodyStyle 등)
+
+### 정리
+표준 명명 규칙을 체화해서 자연스럽게 사용하라.
+철자 규칙은 직관적이고 반드시 따라야하는 규칙이다.
+문법 규칙은 느슨하고 논란도 있는 편이다. 상황에 따라 상식적으로 판단해서 작성하자.
+
+### 참고
+- 자바 언어 명세[JLS, 6.1]