[Item68] 컨벤션 따르기

Item68에서는 일반적으로 통용되는 명명 규칙을 따르라 말한다

자바 언어 자체의 네이밍 규칙은 첫 글자로 $, _, 문자만 올 수 있으며

그 이후로는 어떠한 Unicode 문자든지 올 수 있다는 단순한 규칙으로 이루어져 있다

 

다만 언어의 규칙(Rule)과 관습(Convention)은 다르며 관습이 조금 더 제한적인 형태로 나타난다

규칙과 관습에 대해 더 자세히 알아보고 싶다면 아래 두 글을 참고하자

1. https://www.theserverside.com/feature/Java-naming-conventions-explained

2. https://www.oracle.com/java/technologies/javase/codeconventions-namingconventions.html

 

 

https://cdn.ttgtmedia.com/rms/onlineimages/naming_conventions_in_java-f.png

 

네이밍의 대표적인 방식으로 3가지가 있다

1. 제일 많이 쓰이는 듯한 camelCase

단어 간 구분은 오직 대문자로 나타낸다 (구분을 위한 -, _ 등의 문자 사용을 추천하지 않는다), 상수는 예외로 _ 문자로 구분한다

 

2. 파이썬에서 자주 쓰이는 snake_case

예전에 파이썬을 잠깐 볼 때 Camel Case보다 Snake Case가 사람이 인식하기 더 편하다는 연구 결과로

파이썬에서는 Snake Case를 쓴다고 본 적이 있던 것 같다

 

3. 어디서 쓰이겠는지 모르는 PascalCase

다양한 프로그래밍 언어들의 네이밍 컨벤션에 관한 글에서는 C#에서 쓴다고 하는데

이러면 클래스인지 메서드인지 헷갈리지 않을까 싶다

 

위 내용들은 대략적으로 나타낸 것이고 더 핵심적인 것은 유지보수성을 높이기 위한 팀 자체의 컨벤션이다

자바를 쓰더라도 snake_case를 얼마든지 쓸 수 있고 PascalCase도 쓸 수 있다

팀원들이 합의를 이루면 어떤 컨벤션을 쓰던지 유지 보수하기 편리하고 서로 이해할 수만 있으면 된다

구멍가게 프로젝트를 지나 대규모 프로젝트라면 하나 더 신경 써야 할 것이 생긴다

 

DDD의 Ubiquitous Language, Domain Specific Language와도 관련이 있는 내용으로

두 인자를 더하는 메서드의 이름을 add로 하기로 했다면 프로젝트 전반에서 add라는 네이밍으로 밀고 가야 한다

같은 동작을 수행하는 메서드의 이름이 A 프로젝트에서는 add고 B 프로젝트에서는 plus고 C 프로젝트에서는 increase라면

단순한 메서드 사용에도 의심을 가져야 하고, 그 구현을 세세히 까 봐야 하는 대참사가 날 수 있다

 

객체지향 관련한 책들에서 어디서는 서술적인 메서드를 사용하라 말하고 어디서는 내부 구현을 드러내서는 안 된다

말하는 바람에 한 동안 혼란이 있었는데 내 생각에는 public API에는 적절히 추상화된 이름을 붙이고

내부에서 사용하는 private, package-private에는 내부 구현을 살짝 드러내도 문제없을 것 같다

나도 아직 이름을 내 멋대로 짓는 습관을 버리지 못해서 코드 리뷰 때 깨지곤 하는데 

프로젝트 전체의 메서드에서 개념적 일관성을 유지하기 위해 한 번이라도 찾아보고 이름을 지어야겠다

예전에는 메서드 이름 짓는데 오래 고민하는 게 이해가 안 됐는데 이런 비하인드 스토리가 있었나 보다