클린 코드 2장 - 의미 있는 이름

슬링키의 클린! 코드!

2장에서는 이름을 잘 짓는 간단한 규칙을 몇 가지 소개한다.

---

#1 의도를 분명히 밝혀라

의도가 분명한 이름이 정말로 중요하다.

변수의 존재 이유, 수행 기능, 사용 방법 을 명시적으로 포함하는 이름이 중요하다.

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

 

코드가 복잡하지 않더라도 중요한 것은 코드의 함축성이다.

코드 맥락이 코드 자체에 명시적으로 드러나지 않는 경우 코드에 대한 정보가 부족하게 된다.

변수, 함수가 하는 일을 이름으로써 명확하게 명시하면 코드의 역할 이해가 쉬워진다.

 

이것이 좋은 이름이 주는 위력이다.

---

#2 그릇된 정보를 피하라

프로그래머는 코드에 그릇된 단서를 남겨서는 안된다.

그릇된 단서는 코드 의미를 흐린다.

 

그릇된 단서에 대한 내용은 다음과 같다.

 

널리 쓰이는 의미가 있는 단어를 다른 의미로 사용하면 안된다. (ex. hp, aix, sco)

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

유사한 개념은 유사한 표기법을 사용한다.

 

 

그릇된 단서 예

자료형이 List가 아님에도 변수명에 list가 들어가는 경우

일관성이 떨어지는 표기법 등

---

#3 의미 있게 구분하라

연속된 숫자를 덧붙이거나 불용어(noise word)를 추가하는 방식은 적절치 못하다.

이름이 달라야 한다면 의미도 달라져야 한다.

 

 

연속적인 숫자를 붙이는 등과 같은 이름 설정은 아무런 정보를 제공하지 못한다.

a1, a2, a3 ... an

 

불용어를 추가하는 이름 역시 아무런 정보를 제공하지 못한다.

(Product라는 클래스가 있다고 가정하자.

다른 클래스를 ProductInfo, ProductData라 부른다면

개념을 구분하지 않은 채 이름만 달리한 경우이다.)

 

읽는 사람이 차이를 알도록 이름을 지어라

---

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

사람들은 단어에 능숙하며 단어는 발음이 가능해야한다.

발음하기 어려우면 토론하기에도 어렵다.

최대한 발음하기 쉬운 명칭을 사용하자.

---

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

숫자 및 모음(a,e,i,o,u)같이 많이 사용되는 문자는 피하자.

이름 길이는 범위 크기에 비례해야 한다.

메소드의 기능이 간단할 수록 변수명은 짧아야 한다.

메소드가 복잡할 수록 디테일한 변수명을 지정해준다.

---

#6 인코딩을 피하라

인코딩과 헝가리안 표기법은 자제하라.

멤버변수 접두어에서 m_이라는 접두어 사용할 필요 없다.

인터페이스에서 'I'라는 표기 사용 자제하라.

(IShapeFactory I라는 이름의 접두어를 붙이지 않고 구현클래스에 ShapeFactoryImple 와 같이 표기하는 것이 더 낫다.)

---

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

변수를 선언할 때 단순 반복문에 사용되는 변수에는 한 글자(i, j, k)등은 괜찮다.

하지만 이 외에 다른 변수에는 독자가 코드를 읽으면서

직관적으로 받아들일 수 있는 변수명을 사용하자.

 

명료함이 최고라는 사실

전문가 프로그래머는 자신의 능력을 좋은 방향으로 사용해 남들이 이해하는 코드를 내놓는다.

---

#8 클래스 이름, 메소드 이름

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

(Customer, WikiPage, Account 등)

Manager, Processor, Data, Info등은 피하고 동사는 사용하지 않는다.

 

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

(postPayment, deletePage 등)

접근자, 변경자, 조건자는 javabean 표준에 따라 값 앞에 get, set, is를 붙인다.

---

#9 기발한 이름은 피하라

이름이 너무 기발하면 특정 소수만 그 명칭의 의미를 안다.

재미난 이름보다 명료한 이름을 선택하라.

의도를 분명하고 솔직하게 표현하라.

---

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

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

예를 들어, DeviceManger와 ProtocolController에서와 같이 Controller와 Manager의 근본적 차이가 없다.

따라서 굳이 혼용해서 사용하지 않고,

일관성 있는 단어를 사용해야 한다.

---

#11 말장난을 하지 마라

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

같은 맥락이 아닌데도 '일관성'을 고려하여 같은 이름을 사용하는 경우

맥락이 다르므로 말장난에 더 가깝다고 볼 수 있다.

(Ex. 메소드 작성중에 다른 맥락에서 새로운 add 기능이 생기는 경우,

add라는 단어보다는 append나 insert의 단어로 대체하는게 바람직하다)

 

프로그래머는 코드를 최대한 이해하기 쉽게 짜야 한다.

대충 훑어봐도 이해할 코드 작성이 목표다.

---

#12 해법 , 문제 영역에서 가져온 이름을 사용하라

코드를 읽는 사람도 결국 프로그래머다. 

이러한 점을 고려하였을 때, 알고리즘 이름, 패턴 이름, 수학 용어등을 코드에 사용해도 괜찮다.

또한 문제 영역에서 변수명을 가져와 사용해도 좋다.

 

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

그러면 코드를 보수하는 프로그래머가 분야 전문가에게 의미를 물어 파악할 수 있게 된다.

문제 영역 개념과 관련이 깊은 코드라면 문제 영역에서 이름을 가져와야 한다.

 

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

---

#13 의미 있는 맥락을 추가하라

이름, 단어에 맥락을 부여하자.

단어 그 자체가 맥락을 가지는 경우는 없다.

클래스, 함수, 이름 공간에 따라 맥락이 부여된다.

(firstName, lastName, street, houseNum, city, state 등)

위와 같이 계층에 따른 맥락 부여 실패할 시에는, 접두사를 붙여 사용한다.

(addrFirstName, addrLastName, addrState 등)

 

맥락같은 경우에는 독자가 코드를 읽으면서 파악해야한다.

---

#14  불필요한 맥락을 없애라

의미가 분명한 경우에 한하여, 짧은 이름이 긴 이름보다 낫다.

이름에 불필요한 맥락을 추가하지 않도록 주의한다.

 

(예를 들어, Gas Station Deluxe 어플리케이션 개발에 있어,

클래스 이름을 GSD로 짓는 것과 같은 행위는 자제하자. 아니 피하자.)

 

 

---

 

해당 포스팅 내용은 책 'Clean Code - Robert C. Martin' 출처로 합니다.