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. 불필요한 맥락을 없애라

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

결론

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