💻 의도를 분명히 밝혀라
맥락이 코드 자체에 명시적으로 드러나도록 이름에 정보를 함축하라.
- 나쁜 예
int d; // 경과 시간(단위: 날짜)- 좋은 예
int elapsedTimeInDays;
int daysSinceCreation;
int daysSinceModification;
int fileAgeInDays;💻 그릇된 정보를 피하라
코드의 의미를 흐리지 않도록 하라.
-
널리 쓰이는 의미가 있는 단어를 사용하지 마라
ex)hp,aix,sco -
그룹 변수 이름에 List를 사용하지 마라
ex)accountList→accountGroup,accounts -
서로 유사한 이름을 사용하지 마라
ex)XYZController,ForEfficientHandling,XYZControllerForEfficientHandling
💻 의미 있게 구분하라
읽는 사람이 차이를 알도록 이름을 지어라.
-
연속된 숫자로 이름을 구분하지 마라
ex)copyChars(char a1[], char a2[])→copyChars(char source[], char destination[]) -
불용어로 이름을 구분하지 마라
ex)Product|ProductInfo,ProductData,theProduct,aProduct,Products
ex)SomethingManager|SomethingProcessor
💻 발음하기 쉬운 이름을 사용하라
이미 알고 있는 단어를 효율적으로 활용하라.
💻 검색하기 쉬운 이름을 사용하라
사용 위치를 쉽게 확인할 수 있는 의미있는 이름을 지어라.
💻 인코딩을 피하라
이름에 불필요한 정보를 추가하지 말고 IDE를 활용하라.
- 헝가리식 표기법: 타입을 변수명에 명시하지 마라
- 멤버 변수 접두어
m_: 이름을 다르게 하지 않아도 멤버 변수임을 확인할 수 있어야 한다 - 인터페이스 클래스와 구현 클래스: 예외로, 구체 클래스(concrete class)에
Impl접미어 인코딩은 필요하다
💻 자신의 기억력을 자랑하지 마라
남들이 이해할 수 있고 변경하지 않아도 되는 이름을 사용하라.
💻 클래스 이름
클래스, 객체 이름은 명사나 명사구가 적합하다.
💻 메소드 이름
메소드 이름은 동사나 동사구가 적합하다.
생성자를 중복정의(overload)할 때는 정적 팩토리 메소드를 사용한다.
💻 기발한 이름은 피하라
재미난 이름보다 명료하고 분명한 이름을 선택하라.
💻 한 개념에 한 단어를 사용하라
이름이 다르면 다른 개념으로 인식된다.
💻 말장난을 하지 마라
독자가 의미를 쉽게 해독할 수 있도록 한 단어는 한 가지 목적에만 사용하라.
💻 선 해법 영역, 후 문제 영역에서 가져온 이름을 사용하라
우선 프로그래머가 통용적으로 사용하는 기술 이름을 사용하라.
적절한 '프로그래머 용어'가 없거나, 문제 영역 개념과 관련이 깊은 코드인 경우 문제 영역에서 이름을 가져온다.
💻 의미 있는 맥락을 추가하라
알고리즘, 내용을 읽어야 겨우 유추할 수 있는 이름은 피하라.
💻 불필요한 맥락을 없애라
의미가 분명한 긴 이름을 추구하되, 불필요한 정보를 중복 추가하지 마라
📝 느낀점
모든 규칙이 효과적으로 느껴졌지만, 특히 의미 있는 맥락을 추가하라 규칙의 예시를 읽으면서 좋은 네이밍의 중요성을 실감했다. 내가 간단한 알고리즘 문제를 풀 때 귀찮고 빨리 해치우고 싶어서 자주 하던 짓이 나쁜 예에 그대로 적혀 있어서 굉장히 머쓱했다. 돌이켜 보면, 변수 이름을 대충 지었기 때문에 나중에 다시 그 코드를 볼 때면 한 눈에 파악하기 어려웠다. 그 변수가 어디에 어떻게 쓰이는 지 파악하기 위해서 모든 코드를 다 읽어봐야 했고, 그 안에는 반복되는 코드들이 여러 번 등장했다. 정말 비효율적이고 안 좋은 습관이란 것을 책을 읽으며 다시 한 번 깨달았고, 귀찮더라도 생각을 하고 이름을 짓는 습관을 들여서 나중에 더 큰 프로젝트를 할 때 만족스러운 코드를 짤 수 있도록 노력해야 겠다는 생각이 들었다.
