Java. 명명규칙은 통용되는 것으로 지키자.

 

처음 개발을 시작할 때는 명명규칙이 이렇게나 중요하다는 것을 잘 몰랐다.

 

흔히 통용되거나 그룹에서 따로 지정해놓은 명명규칙을 잘 지키면 아무 문제가 일어나지 않지만,

 

제대로 지키지 않으면 무시무시한 일이 일어난다.

 

일단 시니어의 말을 빌려보자면 코드에서 똥냄새가 난다고 한다.

 

아무리 코드를 잘 짜도 가장 기본이라고 할 수 있는 명명규칙을 지키지 않으면 무시당하기 십상이다.

 

멋들어지게 쓰여진 글이라도 맞춤법을 제대로 지키지 못하는 걸 보면 신뢰도가 확 떨어지지 않는가? 그것과 동일하다고 생각한다. 

 

팀 내 명명규칙을 잘 따르려고 노력했지만 부족한 경험과 영어 실력으로 인해 냄새가 나는 코드를 많이 작성했었다.

 

지금은 어느정도 규칙을 염두해두고 작성하고 있지만, 이렇게 되기까지 많은 지적을 해준 시니어에게 정말 감사하고 느낀다..

 

맞춤법도 제대로 못하는 사람과 같이 일하면 얼마나 어질어질할까? 참으로 고마우신 분들이다.

 

 

 

철자규칙

 

 

패키지와 모듈 이름

 

각 요소를 . 으로 구분하여 계층적으로 짓는다.

 

각 패키지 이름은 소문자를 사용한 8자 이하의 짧은 단어 혹은 약어를 추천하고 명사를 사용한다.

 

예를 들어 utilities 보다는 util 이 좋다.

 

 

클래스와 인터페이스 이름

 

하나 이상의 단어로 이루어지며, 각 단어는 대문자로 시작해야 한다.

 

단어의 첫 글자만 딴 약자나 max, min 처럼 널리 통용되는 줄임말을 제외하고 단어를 줄여 쓰면 안된다.

 

 

 

메서드와 필드 이름

 

첫 글자를 소문자로 쓴다는 점만 빼면 클래스 명명 규칙과 같다. 

 

 

 

상수 필드

 

상수 필드는 예외적으로 모두 대문자로 쓰며 단어 사이는 밑줄로 구분한다.

 

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

 

 

 

타입 매개변수

 

타입 매개변수의 이름은 보통 한 문자로 포함한다.

T : 임의의 타입
E : 컬렉션 원소의 타입
K, V: 맵의 키와 값
X : 예외
R : 메서드 반환 타입
T, U, V (T1, T2, T3) : 임의 타입의 시퀀스

 

 

 

 

문법규칙

 

 

클래스

 

보통 단수 명사나 명사구를 사용한다.

 

1. 객체를 생성할 수 없는 클래스의 이름은 보통 복수형 명사로 짓는다. ex) Collectors

 

2. 인터페이스 이름은 클래스와 똑같거나 able 혹은 ible 로 끝나는 형용사로 짓는다. ex) Runnable, Accessible

 

3. 애너테이션은 명사, 동사, 전치사, 형용사가 두루 쓰인다. ex) Inject, ImplementedBy

 

 

 

메서드

 

어떤 동작을 수행하는 메서드 이름은 동사나 동사구로 짓는다. 단 동사는 현재형이여야 한다. ex) drawImage

 

- is, has : boolean 값을 반환하는 메서드

- 명사, get : 해당 인스턴스의 속성을 반환하면서 반환 타입이 boolean 이 아닌 경우. ex) size, getTime

- toType : 객체의 타입을 바꿔서 다른 타입을 다른 객체를 반환하는 인스턴스 메서드. ex) toString, toArray

- asType : 객체의 내용을 다른 뷰로 보여주는 메서드. ex) asList

- typeValue : 객체의 값을 기본 타입 값으로 반환하는 메서드. ex) intValue

 

 

 

정적 팩터리 이름

 

form, of, valueOf, instance, getInstance, newInstance, getType, newType 을 흔히 사용한다.

 

 

 

필드 이름은 명사/ 명사구를 사용하도록 하자.

 

네이밍을 할 때는 신중히 하도록 하자. 

 

이름만 보고 쓰임새를 유추할 수 있다는 것은 프로그래밍에서 꽤나 신경을 들이는 가독성에도 큰 영향을 끼친다.

 

 

편의 메서드를 너무 많이 만들지 말자.

 

메서드가 너무 많으면 테스트하기 어렵고 사용하는 사람도 힘들다.

 

 

메서드를 작성할 때 매개변수 목록은 짧게 유지하자.

 

4개 이하가 좋으며 같은 타입의 매개변수 여러 개가 연달아 나오는 경우는 특히 해롭다. 

 

실수로 순서가 바뀌어도 컴파일이 되고 후에 런타임에서 에러가 발생해야 매개변수 순서를 잘 못 넣은 것을 확인 할 수 있다.

 

바로 에러가 발생하면 다행이지만, 어느정도 로직이 진행된 후에 발견된다면 문제점을 발견하기 상당히 힘들어 질 수 있다.

 

그렇게되면 매 포스팅마다 쓰는 것 같지만 개발하는 맛이 나서 행복도가 증가하고 협업 시에는 범인으로 특정되어 호감작과 업적작을 할 수 있다. 매우 무서운 상황에 빠질 수 있으니 조심하도록 하자....... 경험담이라는게 참 슬프다.

 

매개변수 목록을 짧게 줄이기 위해선 

 

1. 여러 메서드로 쪼갠다.

2. 매개변수 여러 개를 묶어주는 도우미 클래스를 만든다.

3. 빌더 패턴을 사용한다.

 

 

정도의 방법이 있겠다.

 

또한 매개변수의 타입으로는 클래스보다는 인터페이스가 낫고,

 

boolean 보다는 원소 2개짜리 열거 타입이 낫다.

 

메서드 이름상 boolean을 받아야 하는 경우는 예외지만

 

메서드 매개변수로 Thermometer.newInstance(true) 보다는 Thermometer.newInstance(TemperatureScale.CELSIUIS)가 하는 일을 명확히 알려준다.

 

 

---

위에 까지가 이펙티브 자바 서적에 나온 코딩 컨벤션이고

 

아래는 기존 팀에서 사용하던 코딩 컨벤션이다.

 

1. 불변 객체 사용
2. Collection 의 연산 결과는 불변 객체 반환 
3. final 변수 사용
4. 클래스 이름 파스칼 케이스 사용
5. 변수 이름 카멜 케이스 사용
6. 상수 이름 어퍼 케이스 사용
7. Enum 이름 파스칼 케이스, 요소 이름 어퍼 케이스 사용
8. 클래스 Getter / Setter 사용 ( Lombok )
9. 클래스 모든 생성자 사용 금지
10. 모델 변환시에 매퍼 사용 ( MapStruct )
11. 인텔리제이 코드 스타일 설정
12. 파라미터 2개 이상 줄 바꿈
13. 코드 블럭  대-괄호 다음 줄 바꿈
14. 변수 전체 이름 사용
15. 클래스 / 인터페이스 단일 책임 원칙 준수
16. 클래스 / 인터페이스 전체 이름 사용
17. 상수 클래스 프라이빗 생성자 사용
18. 파라미터 필드 검증 어노테이션 사용
19. 런타임 예외 발생 금지
20. 람다 예외처리 필수
21. Optional 파리미터 사용 금지
22. 싱글톤 Holder 사용
23. 매직 넘버 사용 금지
24. 중복 코드 제거
25. 유닛 테스트 작성

 

명명 규칙 외에도 혼동 될 수 있는 코딩 스타일을 정해놓았다.

 

대체적으로 적어놓은 것만 이정도지 사실 암묵적으로 지키는 것들도 많이 존재했다.

 

이러한 컨벤션이 정해져 있다면 꼭 칼같이 지켜서 깔끔한 코드를 작성해보자.