클린 코드 2장 - 의미 있는 이름
2장에서는 좋은 이름을 짓는 규칙을 몇 가지 소개한다.
첫장에서 후두려 맞고, 2장에서 뼈가 갈렸다. 이사람 분명히 내 코드를 봤다. 읽으면서 부끄러웠고, 공감했고, 이 장을 읽은 이후로 코드 스타일이 많이 바뀌었다.
규칙
의도를 분명히 밝혀라
- int d, list1 → 보고 무슨 의미인지 모를 이름은 쓰지 말자.
- if(x[0] == 4) → x[0]이 뭔지, 4가 뭔지 어케 아냐!
→ if(cell[STATUS_VALUE] == FLAGGED) 이렇게 값에도 이름을 붙여주자.
→ if(cell.isFlagged()) 처럼 상수를 감춰도 좋다.
그릇된 정보를 피하라
- 줄임말이 다른 의미로 쓰이는 단어라면 쓰지 말자.
- List가 아니라면 List라고 적지 말자. 자료형이 List인 것으로 오해할 수도 있다.
- ex) accountList → accounts
- 비슷한 이름도 피하자.
- ex) int lO, int IO, int O1, int 0l . . 이런 짓을 할 사람은 없겠지?
의미 있게 구분하라
불용어 쓰지 말기(a, the 나 x1,x2,x3...과 같은 숫자들, Info,Data 등 의미 없는 단어)
ex) getActiveAccount, getActiveAccountInfo, getActiveAccountData . . 뭘 호출해야 할지 쉽게 이해할 수 없다.
발음하기 쉬운 이름을 사용하라
괜히 약어로 쓰면 팀원들과 의사소통이 힘들어진다
ex) genymdhms - 젠 와이엠디에이치...뭐?
검색하기 쉬운 이름을 사용하라
- 이름을 의미 있게 지으면 함수가 길어진다. 하지만 검색하기는 쉽다.
- 이름 길이는 범위 크기에 비례하는 것이 좋다.
인코딩을 피하라
- 자료형 변수 이름에 쓰지 말자.
- 멤버 변수 접두어 m_ 이런것도 쓰지 말자. 클래스나 함수는 접두어가 필요없을 정도로 작아야 마땅하다.
자신의 기억력을 자랑하지 마라
- 변수 이름을 자신이 아는 이름으로 변환해야 한다면 바람직하지 못하다.
- 명료함이 최고다.
클래스 이름은 명사(구), 함수 이름은 동사(구)가 적절하다.
기발한 이름은 피하라
드립치지 마셈
한 개념에 한 단어를 사용하라
ex) fetch, retrieve, get 등 → 일관성 있게 하나만 사용
말장난 하지 마라
바로 위에서 한 개념에 한 단어 사용하라 했다고, 일관성 있게 하기 위해 맥락이 다른 두 개념을 한 단어로 사용하지도 말자.
ex) 두 값을 더하는 것과 이어 붙이는 것, 둘 다 add라고 하는 멍청한 짓 금지!
해법 영역, 문제(Domain) 영역에서 가져온 이름을 사용하라
- 해법 영역 : 전산 용어, 알고리즘 이름, 패턴 이름 등은 걍 써도 된다. 어차피 읽는 사람도 프로그래머일 것
- 문제 영역 : 적절한 프로그래밍 용어가 없다면 해당 문제와 관련된 도메인에서 이름을 명명한다.
의미 있는 맥락을 추가하고 불필요한 맥락을 없애라
- 변수를 클래스, 함수, namespace 등에 넣어 맥락을 부여한다. 정 안되면 마지막 수단으로 접두어를 붙인다.
- 의미를 분명하게 표현할 수 있다면, 변수명은 짧은 게 좋다. 굳이 필요없는 접두어를 붙이지 말자!
정리
규칙이 . . 생각보다 많다. 물론 다 정답이라는 건 아니다. 읽으면서 의아한 부분도 있을 것이고, 속해있는 팀의 컨벤션도 있을 것이다. 취사선택 하면 된다.
그래도 대부분 끄덕거리면서 읽긴 했죠?
책의 서론에서 얘기했듯, 규칙만 읽는다고 좋은 코드를 짤 수 있는 것이 아니다. 규칙들을 읽고, 예시를 보면서 의도를 파악하고 느껴야 한다.
그런 의미에서, 새로 코드를 짜든, 이전에 쓰레기같이 짠 코드를 개선하든, 좋은 이름에 대해 지속적으로 고민해 봅시다!
Uploaded by Notion2Tistory v1.1.0