[Clean Code] 클린 코드 - 5

자신의 기억력을 자랑하지 마라

자신이 항상 URL을 r이라는 변수에 사용했다면, 자신은 그것을 항상 기억하기 때문에 사용해도 괜찮다고 생각한다.
하지만 정말 능력자들은 자신의 능력을 좋은 방향으로 사용해 남들이 이해하는 코드를 내놓는다.

클래스 이름

명사나 명사구가 적합하다.
Customer, WikiPage, Account, AddressParse 등은 OK
Manager, Processor, Data, Info 등과 같은 단서 X

메서드 이름

동사나 동사구가 적합하다.
postPayment, deletePage, save OK
접근자, 변경자, 조건자는 접두어로 get, set, is 를 붙인다.

Complex fulcrumPoint = Complex.FromRealNumber(23.0); // 정적 팩토리 메소드
vs
Complex fulcrumPoint = new Complext(23.0); // 생성자

생성자를 오버로딩할 때는 정적 팩토리 메서드를 사용한다.

기발한 이름은 피하라

농담이나 유머감각이 비슷한 사람만 알 수 있는 명명을 피하라

한 개념에 한 단어를 사용하라

추상적인 개념 하나에 단어 하나를 선택해 이를 고수한다.

예를 들어, 같은 메서드를 클래스마다 fetch, retrieve, get 으로 제각각 부르면 혼란스럽다.

말장난을 하지마라

한 단어를 두 가지 목적으로 사용하지 마라.
앞선 '한 개념에 한 단어를 사용하라'와 조금은 충돌되는 부분이다.
모든 add 메서드의 매개변수와 반환값이 의미적으로 같으면 상관이 없다.
하지만 같은 맥락이 아닌데도 '일관성' 을 고려해 add라는 단어를 선택한다.
ex) 지금까지의 add메서드는 2개의 값을 더하거나 새로운 값을 만든다고 가정하자.
새로 작성하는 메서드는 집합에 값 하나를 추가한다.
이 메서드도 add라고 불러도 괜찮은가? -> insert나 append의 이름이 적합하지 않을까? -> 의미가 다르니

해법 영역에서 가져온 이름을 사용하라

코드를 읽을 사람도 프로그래머이다.
전산 용어, 프로그래머 용어, 알고리즘 이름, 패턴이름, 수학 용어 등을 사용해도 무방하다
ex) Visitor 패턴에 친숙한 프로그래머는 AccountVisitor라는 이름을 금방 알 것이다.
JobQueue, ReadyQueue를 모르는 프로그래머는 없을 것이다.

문제 영역에서 가져온 이름을 사용하라

적절한 프로그래머들의 용어가 없다면 문제 영역에서 이름을 가져온다.

의미있는 맥락을 추가하라

스스로 의미가 분명한 이름이 있다. 하지만 대부분의 이름은 그렇지 못하다
그래서 클래스, 함수, 이름 공간에 넣어 맥락을 부여한다.
firstName, lastName, street, houseNumber, city, state, zipcode라는 변수가 있다. 변수를 보면 "주소"라는 사실을 금방 알아챈다.

하지만 어느 메서드가 state라는 변수를 하나만 사용한다면? 해당 state가 주소의 state인지 상태인지 모를 것이다.
따라서 이럴 때는 접두어를 붙여서 맥락을 분명히 한다. addrState 처럼

마치며

좋은 이름을 선택하려면 설명 능력이 뛰어나야하고 문화적 배경이 같아야한다.
사람들이 이름을 바꾸지 않으려는 이유 중 하나는 다른 개발자가 반대할까 두려워서이다.
하지만 좋은 이름으로 바꾼다면 그것은 고마운 일이다. 따라서 개선하려는 노력을 중단해서는 안 된다.