[요약] 2.의미 있는 이름

1. 올바른 이름이란

변수명/클래스명/함수명은 아래의 질문에 답할 수 있어야 한다. 

- 변수(클래스,함수)의 존재 이유

- 수행 기능

- 사용 방법

 

역할이 제대로 명시된 이름과 그렇지 않은 이름을 비교해보자. 

/*bad*/
ind day; // 경과 시간 (단위, 날짜)

/*good*/
int daySinceCreation;

위 코드의 bad는 주석이 있기 때문에 괜찮지 않냐고 물을 수도 있다.

하지만 day를 여러 곳에서 사용한다면 어떨까.

유지보수를 하는 나 같은 사람은 최초 작성자의 의도를 읽기 위해 매번 주석이 정의된 곳으로 스크롤을 왔다갔다할 것이다.

사실 내가 짠 과거의 코드도 저런 모습이 많다.. 반성하자 내 자신

2. 나쁜 이름과 좋은 이름의 예시

2.1 이름에 포함된 자료형 -> Bad

/*bad*/
List<String> userList; //나중에 Array로 바뀌면 혼란스럽지 않을까?

/*good*/
List<String> users;

2.2 서로 흡사한 이름 -> Bad

예) 두 클래스의 차이를 알 수 없다. 

UserRegistration
USerResgist

2.3 불용어(noise word)를 포함 -> Bad

/*bad*/

Map<String,Object> userData;

Map<string,object> classInfo;

 

* 불용어란: 너무 흔해서 유용한 정보를 못 주는 경우

- A noise word is a word such as the or if that is so common that it is not useful in searches.

2.4 인코딩 정보 포함 -> Bad

인코딩정보(Type)까지 이름에 넣었을 때를 의미한다. 

 

2.4.1 헝가리식 표기법

sz는 과거 string임을 알리기 위해 썼던 명명법.

컴파일러가 변수 타입을 체크하지 않던 과거에나 필요. 지금은 필요 없다. 

String szStudentId;

 

2.4.2 멤버 변수 접두어 

클래스, 함수는 작아지므로, 멤버변수를 굳이 표시할 필요 없다. 

public class Student {
	private String m_name; // 학생 이름
}

 

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

인터페이스 앞에 굳이 I(Interface를 뜻함)를 붙여 ICar, IAnimanl이라 할 필요 없다.

인터페이스를 호출하는 클라이언트 단에 "나 인터페이스요"하고 불필요한 정보를 제공하는 꼴이다. 

2.5 발음하기 쉬운 이름 -> Good

/*bad*/
genymdhms; // generate date, year, month, day, hour, minutes, seconds

/*good*/
geneartionTimeStamp

2.6 검색하기 쉬운 이름 -> Good

/*bad*/
int Random().nextInt(10)

/*good*/
final int MAX_RANDOM_NUMBER = 10;

int Random().nextInt( MAX_RANDOM_NUMBER );

/* 참고 Random().nextInt (n)은 0<(숫자)<n 범위의 (숫자)를 리턴한다. */

3. 클래스 , 메서드 명명법

3.1 클래스명은 명사, 명사구로 짓자

/*good*/

Customer, Student, AddressParser

/*bad*/

Data, Info, Manager // 불용어 사용 하지 말자

3.2 메서드명은 동사나 동사구로 

- 접근자: get~ 

getCharacterName()

- 변경자: set~

setChracterName()

- 조건자: is~

isGameOver()

- 생성자: 중복 정의할 경우 정적 팩터리 메서드 사용

  (32p 예제, 하단 정적 팩터리 메서드 설명 url 참고)

3.3 일관성있는 어휘를 사용하자. 

예) 컨트롤러를 Controller, Manager, Driver등으로 섞어서 명명하면 개념을 이해하기 어렵다.

3.4 도메인 전문 용어가 필요할 경우 사용하자 

이북 리더기 프로그램을 서비스하는 회사가 있다. 

가장 최근 발매된 도서를 가져올 때 아래 2가지 중 어느 것이 나은가

/*bad*/
getBookTableLastRow // BOOK 테이블의 마지막 row를 가져온다 .

/*good*/
getLatelyReleasedBook

3.5 기술 용어가 필요하다면 사용하자

맛집 대기 서비스가 있다. 현재 대기중인 사용자를 명시할 때 아래 2가지 중 어느 것이 나을까

/*bad (혹은 good 보다는 못한) */
Queue<User> usersWaiting

/*good*/
Queue<User> userQueue

4. 맥락의 구분

잘 짜여진 코드는 매 Line이 의도를 드러낸다.

의도는 어떻게 드러낼까? 4.1과 4.2를 보자

4.1 하나의 함수안에 많은 개념이 들어가 있다면 클래스와 메서드로 쪼개라.

설명 대신 35~36p 코드 참고

4.2 불필요한 맥락을 없애라

블로그 플랫폼을 만든다고 하자.

클래스 명을 BlogPosting, BlogUesrs, BlogVisitiors 식으로 만든다면 어떨까?

- Blog라는 접두사는 매번 붙기 때문에 불필요한 내용이되어 프로그래머가 무시하는 정보가 된다.

- 블로그를 추후 Blogi라고 부를 때 Blog를 어떻게 처리해야하나 고민해 빠진다. (Blog 접두사를 사용하는 곳이 많다면 재앙 수준 ㅇㅅㅇ)

5. [2장]을 마치며

5.1 느낀점

개인적으로 3.4과 3.5가 가장 공감이 갔다.

나는 개발자지만, 현재 유지보수하는 서비스의 모든 테이블을 알지는 못한다.

그런데 테이블명을 메서드명에 적어두면 주석에 의존하거나 코드 가장 밑 부분까지 뜯어봐야하는 난감함이 발생한다.

가장 난감한 경우는 주석이 메서드의 역할과 불일치하는 최악의 상황...

메서드명은 비즈니스 용어를 쓸 때와 개발 용어를 쓸 때를 명확히 구분해야 한다. 

5.2 레퍼런스 

[1]불용어(noise word)

https://care.icims.com/s/article/Understanding-Search-Noise-Words#:~:text=A%20noise%20word%20is%20a,in%20the%20iCIMS%20Hiring%20Suite.

 

[2] 정적 패터리 메서드

https://johngrib.github.io/wiki/static-factory-method-pattern/

 

* 본 포스팅은 '클린코드 도서' 스터디를 진행하며 작성하였습니다.

* 클린코드 도서 구매 링크: https://www.aladin.co.kr/shop/wproduct.aspx?ItemId=34083680 

클린 코드 Clean Code