클린 코드 Chapter 2에서는 네이밍에 대해 말한다.
물론, 클린 코드 저자가 밝혔듯이 개발자들과 함께 일하면서 이런건 지켜야 편하다는 주관적 기준이 섞였기에 무조건적으로 지킬 필요는 없다.
하지만, 어느 정도 참고하면서 네이밍을 짜면 좋은 규칙들임은 분명하다.
저자는 시작하기 전에 이 말을 하고 시작한다.
코드를 읽는 것은 결국 프로그래머다.
그렇다. 코드의 가독성을 높이는 건 다름아닌 언젠간 본인이 될 수도 있는 코드 읽기에 해당한다. 기존 코드를 볼 때 100%가 걸리면 이 때 90%가 코드 읽고 파악하기다. 그러므로 프로그래머에게 코드 가독성은 아주아주 중요한 문제라고 할 수 있다.
저자가 말하는, 지키면 좋을 네이밍 규칙들을 같이 살펴 보자
1. 의도를 분명히 밝혀라.
변수(혹은 함수, 클래스 등)명을 작성할 때 고민을 해봐라
- 변수의 존재 이유는?
- 변수가 수행하는 기능은?
- 이 변수를 어디서 사용하는지?
등등 주석이 필요한 네이밍은 의도가 정확하지 않는 네이밍이다.
2. 그릇된 정보를 피하라.
실제 변수의 자료형이 List가 아닌데 네이밍에 list가 포함하는 걸 추천하지 않는다.
물론, 컨테이너가 List인 경우라도 컨테이너 유형을 이름에 넣지 않는 편이 바람직하다.
3. 의미있게 구분하라.
동일한 범위 안에서는 다른 두 개념에 같은 이름을 사용하지 못한다.
즉, 노트 작성하기 위한 기능을 위해 다른 클래스에서 apple이라는 변수를 썼는데 또 다른 클래스에서 apple이라는 변수를 쓰면 아무리 프로 개발자여도 단 번에 이해하기 어려울 것이다.
읽는 사람이 차이를 알도록 이름을 짓자.
4. 발음하기 쉬운 이름을 사용하라.
만약 date, year, day, timestamp 를 줄여서 dydt라고 쓴다고 생각해보라. 회사에 막 입사한 신규개발자에게 이름이 뭔지부터 설명해야하고 히스토리를 주구장창 말해야할 것이다.
심지어 서로 개발자끼리 '그 디 와이 디 티 말야...' , '..둇트 말이지?' 천차만별로 불렸다면 소통하는데 한 차례 어려움을 겪을 것이다.
5. 검색하기 쉬운 이름을 사용하라.
클래스가 많아지고 찾을 변수명이 많아지면서 우리는 일일이 기억하지 않는다.
IDE 힘을 빌려 검색을 하는데 이 때 찾을 변수가 5, e 라던지 이런 잦고 의미불명의 변수라면 찾는데 한참 걸릴 것이다.
기능을 파악하고 해당 기능에 맞는 네이밍을 떠올려 검색하는데 쉬운 이름이면 좀 더 편리할 것이다.
6. 인코딩을 피하라.
헝가리식 표기법이란, 변수 이름을 정할 때 이름만으로도 변수 타입을 짐작할 수 있도록 접두사를 덧붙이는 방법.
ex) word라는 이름의 변수는 첫 글자인 w만으로 핸들 타입이라는 것을 알 수 있다.
컴파일러 성능이 좋지 않을 때, (ex. 윈도우 c api) 프로그래머가 자료형 타입도 알아야했기 때문에 해당 표기법을 썼지만, 현대에서는 변수 이름에 타입을 인코딩할 필요가 없다.
IDE에서 컴파일을 하지 않고도 타입 오류를 감지할 수 있다. 따라서 헝가리식 표기법이나 기타 인코딩 방식이 오히려 방해가 된다.
번외
- 때론 인코딩이 필요한 경우도 있다.
도형을 생성하는 ABSTRACT FACTORY를 구현하다고 가정하자. 이 팩토리는 인터페이스 클래스다. 구현은 구체 클래스(concreate class)에서 한다. 이때 이름은IShapeFactory와ShapeFactory? 접두어는 주의를 흐트리고 과도한 정보를 제공한다. 그저 ShapeFactory라고만 생각하면 좋겠다 싶어 무조건 한쪽만 이름을 인코딩 해야한다면 구현 클래스 이름을 택하겠다.
ShapeFactoryImp나 심지어CShapeFactory가IShapeFactory보다 좋다.
7. 자신의 기억력을 자랑하지 마라.
본인만이 아는 네이밍 규칙으로 이름을 정해서 천년만년 회사와 연락하고 싶다면 자랑해도 좋다. 그게 아니면 아래와 같이 정하자.
클래스 이름
명사나 명사구를 쓴다. 동사는 사용하지 않는다.
Customer, Account, AddressParser
Manager, Processor, Data, Info 같은 단어는 피한다. (왜?)
메서드 이름
동사나 동사구를 쓴다.
접근자/변경자/조건자는 javabean 표준에 따라 get, set, is를 붙인다.
생성자를 중복 정의할 때는 정적 팩토리 메서드를 사용한다.
saveData, deletePage
Complex point = Complex.FromRealNumber(23.0) -> O
Complex point = new Complex(23.0) -> X
8. 기발한 이름은 피하라.
단순히 자기들만 아는 단어나 자기 지역 사람들만 아는 숙어, 은어와 같은 단어를 사용하는 것은 다른 사람들이 말하기도 어렵고 의미를 파악하기 어렵다.
모두가 알 수 있는 단어를 사용해서 의미 파악을 쉽게 하다.
발음하기 쉬운 단어 또한 잘 알지 못하는 단어일 확률이 높다. 혹은 직접 만든 단어이거나.
9. 한 개념에 한 단어를 사용하라.
추상적인 개념 하나에 단어 하나를 선택해 이를 고수해라. get을 fetch, retrieve로 여러 영어 단어로 표현하는 것은 굉장히 이해하기 어렵고 다른 의미를 가지고 있다고 생각할 수 있다. 그러니 같은 개념이면 같은 단어를 사용하는 것이 좋다.
그런 예로 DeviceManager와 ProtocalController는 근본적으로 어떻게 다른것인가? 어째서 둘 다 controller, manager로 될 수가 없는 것인가? 둘 다 다른 일을 하는것인가? 일관성 있는 어휘는 코드를 사용할 프로그래머에게 굉장히 큰 도움이 된다.
10. 말장난을 하지마라.
한 단어를 두 가지 목적으로 사용하면 안된다. 다른 개념에 같은 단어를 사용하는 것은 말장난에 불과하다.
어느정도 비슷해 보이는 상황에서 add를 하는 메소드를 만들었다고 가정하자.
예를 들면 값을 더하고 리턴하는 add를 만들었는데 어떤 경우에는 값을 더하지만 리턴하지 않는데 메서드 명에 add를 사용하는 것은 좋지 않다. 차라리 그런 메소드에는 append나 insert와 같은 다른 이름을 붙여야 한다.
11. 해법 영역에서 가져온 이름을 사용하라.
코드를 읽는 사람들은 프로그래머다. 전산 용어, 수학, 패턴 이런 것들에 대해서 기본적으로 알고 있기 때문에 오히려 네이밍에 있어서 좋은 영향을 줄 수 있다.
- 사족
이 부분은 책을 읽을 때 해법 영역이 뭐야?하고 이해가 되지 않았다. 그러나 다른 분들이 쓰신 것도 참고하며 정리하니, 아무래도 프로그래머들은 배경 지식이 비슷하니깐 그 전문 영역을 해법 영역이라하고 그 영역에서 가져온 용어를 뜻한다.
한마디로 Factory라는 뜻을 비개발자들은 한 번에 인식하기 어렵지만 개발자들은 아는 거처럼 말이다.
12. 문제 영역에서 가져온 이름을 사용하라.
해법 영역에서 알맞는 이름이 없다면 문제 영역에서 이름을 가져오자.
해당 영역에 대한 도메인 존재하지 않더라도 꾸준히 개발하는 과정에서 문제 영역에 용어를 알아가게 되고 그것을 통해서 이해가 되는 경우가 많은 것이다. 그러기에 문제 영역에 관련 깊은 영어를 사용해보자.
13. 의미 있는 맥락을 추가하라.
이름 하나만으로 의미가 있는 경우가 있다. 하지만 대부분 이름 하나로는 모든 의미를 알 수 없다. 그래서 함수, 클래스, 이름 공간에 넣어서 맥락을 부여한다.
예를 들면, street, city, state 이런 정보를 보게 되었을 때 어떤 맥락인지 알 수 있다. 하지만 단순히 state만 존재한다면 그 의미를 파악하기가 어렵다.
그런 의미에서 함수에서 맥락 조금, 이름에서 맥락 조금, 알고리즘에서 최종 맥락을 파악하기 보다는 큰 클래스를 만들어서 그것에 대한 이름들에 대해서 맥락을 확실히 부여하고 그 클래스 밑에 여러 메소드를 만들면서 맥락을 명확하게 부여하게 되면 어떤 의미인지 더욱 파악하기가 쉽게 된다.
14. 불필요한 맥락을 없애라.
메모 작성 어플리케이션을 만드는데 모든 클래스 이름에 Memo라는 이름을 붙일 것인가?
IDE에서 M만 검색하기만 해도 모든 클래스가 다 나오게 될 것이다.
이름은 긴 이름보다 짧은 이름이 좋다.
단 그 이름이 모든 내용을 포함하고 있을 때이다. 이름에 불필요한 맥락을 추가하지 않도록 주의하자.
