> For the complete documentation index, see [llms.txt](https://simian114.gitbook.io/blog/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://simian114.gitbook.io/blog/undefined-1/odds_and_ends/undefined/clean_code/chapter2.md).

# Chapter2. 의미있는 이름

이름 하나 만으로 맥락을 파악할 수 있어야 한다.ß

## 이름을 짓는 규칙

### 1. 의도를 분명히 밝혀라

"의도가 분명하게 이름을 지어라." 중요하다는 100줄 이상의 코드를 짜 본 사람이라면 모두가 아는 사실이다. 하지만 의도가 분명하게 이름을 짓는건 생각보다 어렵다. 어떻게 하면 이름에서 그 의도가 명백히 들어날 수 있을까? 정답은 `추상화`에 있는 것 같다. 추상화를 하면 코드가 추상이라는 껍질 안에 숨고 코드를 보는 사람은 보다 인간에게 친숙한 언어로 코드를 볼 수 있다. 예는 1장에서의 추상을 생각하면 될 것 같다.

### 2. 그릇된 정보를 피하라

* 흡사한 이름은 사용하지 않는다.
* 나름대로 널리 쓰이는 의미가 있는 단어를 다른 의미로 사용하면 안된다.
  * `hp`, `aix`, `sco` 등의 단어는 최대한 삼가자.
* `List`라는 이름은 정말로 `list` 자료구조를 사용하는게 아니라면 사용하지 말자. `group`과 같은 다른 단어를 선택하자.

### 3. 의미 있게 구분하라

* 같은 이름을 가진 변수는 있을 수 없다. 만약 비슷한 동작을 하기 때문에 같은 이름을 지었고, 컴파일 에러가 발생해 이름을 바꿔야 하는 상황이 있다고 해보자. 이 때 이름을 생각하고 새로 짓는게 번거롭다는 마음에 이름에 `1`과 같이 숫자를 붙이는 행동은 절대로 하지 말자.
* 또한 `Info`나 `Data`, `a`, `the` 와 같은 단어는 의미가 불분명한 불용어다. 불용어는 중복이나 다름없다. 아래의 두 메써드는 `info`의 차이가 있다. 혹시 이 두 함수의 이름을 보고 각각이 어떤 차이가 있는지 알 수 있는가? 없다. 즉 `info`는 의미가 없는, 중복된 불용어다.
  * `getAccount`
  * `getAccountInfo`

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

* `APPLE` 발음이 너무 쉽다. 애플이 그래서 성공한 걸까?ㅎㅎ

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

* 검색하기 쉬운 이름일 수록 프로젝트의 단위가 커질 수록 그 위력을 발휘한다.

### 6. 인코딩을 피하라

* 헝가리식 표기법, 멤버 변수 접두어
  * 옛날에, IDE 와 같은 툴이 발달하기 전에는 변수 자체에 대해 정보를 알아내기가 어려웠다. 따라서 변수 하나가 대부분의 정보를 포함하고 있어야했다. 따라서 헝가리식 표기법, 멤버 변수 접두어 등을 사용했는데 이제는 시간이 흘렀다. 따라서 굳이 위 두가지 방법을 사용할 필요는 없다.
* 인터페이스 클래스와 구현 클래스
  * 흠.. 난 동의하지 못한다. 인터페이스 클래스는 `I` 접두어를 붙이는게 좋다고 생각한다.

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

### 8. 클래스 이름

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

* 좋은 예
  * `Customer`, `WikiPage`, `Account`
* 나쁜 예
  * `Manager`, `Processor`, `Data`, `Info`

### 9. 메써드 이름

동사나 동사구가 적합하다. 접근자 변경자, 조건자는 `get`, `set`, `is`를 붙이자.

### 10. 기발한 이름은 피하라

나만 알아 볼 수있는 기발한 이름은 사용하지 말자. 코드는 공공재다.

### 11. 개념 하나에 단어 하나를 사용하라

메써드의 이름은 독자적이고 일관적이어야 한다. 그래야만 주석을 뒤지지 않고서도 올바르게 사용할 수 있다. 예를 들어 `fetch`, `retrieve`, `get` 이 셋의 정확한 차이를 아는가? 말을 할 때도 그렇지만 코드로 짤 때는 더욱 신중하게 하나의 이름을 일관적으로 사용해야한다.

### 12. 말장난을 하지 마라

한 단어를 두 가지 의미로 사용하지 마라. `11` 에서 하나의 개념에는 단어 하나만을 사용하라고 했다. `add` 라는 이름을 생각해보자. `add`는 `무엇인가 추가가 된다` 라는 의미를 가진다. 새로운 메써드를 만들어보자. 이 메써드는 `집합에 값 하나를 추가`한다. 에 새롭게 만들어지는 메써드에 `add` 라는 이름을 붙여야 할까? 일관성을 지키려면 그렇게 해야하지! `아니다!` 새롭게 만든 메써드는 `add` 와는 `맥락`이 다르다! 지금은 `append`가 더 어울린다. 따라서 새 메써드를 `add` 로 부르는 것은 말장난이다. 프로그래머는 최대한 이해가 쉽게 코드를 만들어야 한다. 즉, 맥락이 정말 중요하다.

### 13. 해법 영역에서 사용하는 이름을 사용하라

익숙한 단어가 최고다.

### 14. 문제 영역과 관련 있는 이름을 사용하라

당연한 이야기다. 만약 우주선을 쏘아 올려야 하는 프로젝트를 진행중인다. 뜬금 없이 `배` 에서 사용하는 용어를 이름으로 사용하면 될까?

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

맥락을 추가하라는 것은 `읽기 쉽게` 만드는 것을 의미한다. `addDataToCGI`와 같이 이름 하나로 그 맥락을 파악하게 만드는 것이 핵심.

### 16. 불필요한 맥락을 없애라

당연하게도 불필요한 맥락이 있을 수 있다. 이런 경우는 없도록 만들자.

## 결론

당연한 이야기다. 당연한 이야기를 읽고 글로 정리했다. 하지만 나는 제대로 된 이름을 부여하지 않았다. 왜 그랬을까... 변명을 해보자면 코드를 작성하기 전에는 머릿속으로 먼저 청사진을 그려놓는다. 이후에는 청사진이 지워질라.. 노심초사 하면서 얼른 얼른 코드를 짠다. 이 때는 이름을 짓는 시간도 아까워서 신경쓰지 않고 만든다. 물론! 나중에 바꿔야지 라는 생각을 한다. 하지만 `르블랑의 법칙`은 나를 배신하지 않는다. 그렇게 나는 신경쓰지 않은 이름을 가진 코드 그 상태로 팀원분들에게 코드리뷰를 받고 지적을 받는다. 이제는 바뀌어야 한다. 클린코드라는 것은 의도적으로 클린 코드라는 것을 의식해야만 되는 것 같다. 이제부터는 의식적으로 이름을 신경써서 짓도록 해야겠다. 글쓴이는 결론 부분에서 말한다. 프로그래머는 `읽히는 코드를 짜는 데만 집중해야 한다`라고. 프로그래머가 코드를 머릿속에 외우는 시대는 지났다. 외우는건 `멍청한 바보 상자`가 해준다. 우리는 오롯이 읽기만 하면 머릿속에 쏙쏙 들어오는 코드를 짜야한다.