(클린코드) 2장. 의미있는 이름

2장. 의미있는 이름

들어가면서

이름을 잘 지으면 여러모로 편하다. 이름을 잘 짓는 규칙을 몇 가지 소개한다.

의도를 분명히 밝혀라

의도가 분명하게 이름을 지으라

좋은 이름을 지으려면 시간이 걸리지만 좋은 이름으로 절약하는 시간이 훨씬 더 많다.

변수/함수/클래스의 존재이유는? 수행기능은? 사용방법은?

int d;//경과 시간(단위: 날짜)

int elapsedTimeInDay;
int daysSinceCreation;
int daysSinceModification;
int fileAgeInDays

의도가 들어나는 이름을 사용하면 코드 이해와 변경이 쉬워진다

코드 맥락이 코드 자체에 명시적으로 드러나게하기.

변수에 이름을 잘 붙여서 함축성을 줄이고 코드는 더 명확하게 만들 수 있다. 함수가 하는일을 이해하기 쉬워진다.

그릇된 정보를 피하라

여러 계정의 그룹으로 묶을 때 실제 list가 아니라면 ~list라 명명하지 않는다.

널리 쓰이는 의미가 있는 단어를 다른의미로 사용하면 안된다.

서로 흡사한 이름을 사용하지 않도록 주의한다.

의미 있게 구별하라

발음하기 쉬운 이름을 사용하라

줄임말 x

검색하기 쉬운 이름을 사용하라

이름과 상수는 텍스트 코드에서 쉽게 눈에 띄지 않는다라는 문제점

인코딩을 피하라

헝가리식 표기법

과거에는 컴파일러가 타입을 점검하지 않았으므로 프로그래머가 타입을 기억할 단서가 필요했다. 하지만 요즘 IDE는 코드를 컴파일하지 않고도 타입 오류를 감지할 정도로 발전했다. 따라서 인코딩 박식이 오히려 방해가 될 뿐이다.

변수/함수/클래스 이름이나 타입을 바꾸기가 어려워지며 읽기 어려워지고 독자를 오도할 가능성도 커진다.

멤버 변수 접두어

멤버 변수에 m_이라는 접두어를 붙일 필요도 없다. (IDE에서 멤버변수를 다른 색상으로 표시하거나 눈에 띄게 보여줌)

클래스와 함수는 접두어가 필요없을 정도로 작아야 마땅하다.

결국 접두어는 옛날에 작성한 구닥다리 코드라는 징표가 되버린다.

인터페이스 클래스와 구현 클래스

abstract factory (interface class),

인터페이스 클래스, 구현(구체) 클래스

IShapeFactory, ShapeFactory (비추)

ShapeFactory, ShapeFactoryImp 또는 CShapeFactory (위에줄보단 아랫줄이 낫다.)

인터페이스 이름에 I를 붙이는 것보다 구현 클래스이름에 인코딩하는 것을 택하겠다.

내가 다루는 클래스가 인터페이스임을 남에게 알리고 싶지 않다.

(완벽히 이해가 되진 않는다, 무슨의미 일까?? 인터페이스 임을 알리는 것이 어떤 단점이 있는 것기에 차라리 구현 클래스를 알리는 쪽이 낫다는 걸까?)

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

문자 하나만 사용하는 변수 이름은 문제가 있다. (루프i, j, k 는 예외)

최악은 이미 a, b를 사용하므로 c를 선택한다는 논리다.

r이라는 변수가 호스트와 프로토콜을 제외한 소문자 URL 이라는 사실을 언제나 기억하는 똑똑한 프로그래머. 똑똑한 프로그래머와 전문가 프로그래머 사이에서 나타나는 차이점중 하나는 전문가 프로그래머는 명료함이 최고라는 사실을 안다. 전문가 프로그래머는 자신의 능력을 좋은 방향으로 사용해 남들이 이해하는 코드를 내 놓는다.

클래스 이름

클래스 이름과 객체 이름은 명사나 명사구가 적합하다.

Good : Customer, WikiPage, Account, AddressParser

Not good : Manager, Processor, Data, Info 는 피하자.

동사는 사용하지 않는다.

메서드 이름

메서드 이름은 동사나 동사구가 적합하다.

Good : postPayment, deletePage, save

접근자, 변경자, 조건자는 get, set, is를 붙인다.

생성자를 overload(중복정의)를 할 때는 정적 팩토리 메소드를 사용한다.

메서드는 인수를 설명하는 이름을 사용한다.

Complex fulcrumPoint = Complex.FromRealNumber(23.0);

//위의 코드가 아래코드보다 좋다.
Complex fulcrumPoint = new Complex(23.0);

생성자 사용을 제한하려면 해당 생성자를 private로 선언한다.

기발한 이름은 피하라

재미난 이름보다 명료한 이름을 선택하라. 특정 문화에서만 사용하는 농담은 피하는 편이 좋다. 의도를 분명하고 솔직하게 표현하라.

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

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

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

일관성 있는 어휘는 코드를 사용할 프로그래머가 반갑게 여길 선물이다.

말장난을 하지 마라

한 단어를 두 가지 목적으로 사용하지 마라.

기존에 add라는 메소드가 많으니 일관성을 지키려면 동작이 다르더라도 add라고 지어야하나? No.

기존의 add 메서드와 맥락이 다르다. 그러므로 insert나 append라는 이름이 적당하다. 새 메서드를 add라고 부른다면 이는 말장난이다.

프로그래머는 코드를 최대한 이해하기 쉽게 짜야한다. 집중적인 탐구가 필요한 코드가 아닌 대충 훑어봐도 이해할 코드 작성이 목표다.

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

코드를 읽을 사람도 프로그래머라는 사실을 명심한다. 프로그래머에게 익숙한 기술 개념은 아주 많다. 기술 개념에는 기술 이름이 가장 적합한 선택이다.

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

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

우수한 프로그래머와 설계자라면 해법 영역과 문제 영역을 구분할 줄 알아야한다.

의미있는 맥락을 추가하라

스스로 의미가 분명한 이름을 짓기위해서 클래스, 함수, 이름 공간에 넣어 맥락을 부여한다. 하지만 모든 방법이 실패하면 마지막 수단으로 접두어를 붙인다.

주소 일부로 사용되는 변수이름의 경우 아래처럼 쓰는 것이 더 낫다.

ex) state > addrState, firstName > addrFirstName,

물론 Address라는 클래스를 생서하면 더 좋다.

함수이름은 맥락일부만 제공하며, 알고리즘이 나머지 맥락을 제공하게 둬서는 안된다.

변수를 목적에 맞게 클래스로 나누고 함수를 쪼개서 명확히 만들자.

불필요한 맥락을 없에라

일반적으로 짧은 이름이 긴 이름보다 좋다. 단, 의미가 분명한 경우에 한해서다. 이름에 불필요한 맥락을 추가하지 않도록 주의한다.

마치면서

좋은 이름을 선택하려면 설명 능력이 뛰어나야 하고 문화적인 배경이 같아야 한다. (이것이 제일 어렵다.)

좋은 이름을 선택하는 것은 교육의 문제다.

코드를 개선하려는 노력을 중단해서는 안된다.

이 장에서 소개한 규칙 몇개를 적용해 코드 가독성이 높아지는지 살펴보라. 다른 사람이 짠 코드를 손본다면 리팩터링 도구를 사용해 문제 해결 목적으로 이름을 개선하라. 단기적인 효과는 물론 장기적인 이익도 보장한다.