의도를 분명히 밝혀라
- 좋은 이름을 지으려면 시간이 많이 걸리지만, 좋은 이름으로 절약하는 시간이 훨씬 더 많다.
- 이름은 대상의 존재 이유, 수행 기능, 사용 방법을 드러내야 한다.
- 주석이 필요하다면 의도를 분명히 드러내지 못했다는 말이다.
- 단순히 이름만 고쳐도 함수가 하는 일을 이해하기 쉽다.
그릇된 정보를 피하라
그릇된 단서를 남기지 않는다.
널리 쓰이는 의미가 있는 단어를 사용하지 않는다.
예시 1 ) 직각삼각형의 빗변(hypotenuse)을 구현할 때 변수명 hp는 적당하지 않다. 유닉스 플랫폼을 가리키는 이름이기 때문이다.
그룹으로 묶은 의미를 사용할 때, 실제 List를 사용하지 않았다면 accountList와 같이 명명하지 않는다. 실제 List가 아니라면 프로그래머에게 그릇된 정보를 제공하는 셈이다.(실제 컨테이너가 List라도 컨테이너 유형을 이름에 넣지 않는 것이 바람직함)
서로 흡사한 이름을 사용하지 않도록 주의한다. 한 모듈에서 XYZControllerForEfficientHandlingOfStrings 라는 이름을 사용하고, 조금 떨어진 모듈에서 XYZControllerForEfficientStorageOfStrings 라는 이름을 사용하면? 너무 비슷하다.
- 유사한 개념은 유사한 표기법을 사용한다. 일관성이 떨어지는 표기법은 그릇된 정보다.
- 코드 자동 완성 기능을 사용하자. 자동 후보 목록을 활용하자.
의미 있게 구분하라
컴파일러나 인터프리터만 통과하려는 생각으로 구현하지 마라. 철자를 살짝 바꿨다가 나중에 철자 오류를 고치는 순간 컴파일이 불가능한 상황에 빠진다.(예 : class : klass)
컴파일러를 통과하더라도 연속된 숫자를 덧붙이거나 불용어(noise word)를 추가하지 마라. 이름이 다르면 의미도 달라야 한다. (예 : a1, a2)
- 불용어의 예시 : Product 라는 클래스가 있다. 이 때 다른 클래스의 이름을 ProductInfo, ProductData 라고 하는 것은, 개념을 구분하지 않은 채 이름만 달리한 경우다.
- 불용어는 중복이다. 변수 이름에 variable, 표 이름에 table... NameString이 Name보다 나은 점이 없다. Customer라는 클래스와 CustomerObject 라는 클래스의 의미에 차이는 없다.
- 또 다른 예시 : getActiveAccount(); | getActiveAccounts(); | getActiveAccountInfo();
- 또 다른 예시 : (moneyAmount | money), (customerInfo | customer), (accountData | account), (theMessage | message) -> 서로 구분이 안 된다.
발음하기 쉬운 이름을 사용하라
- 발음하기 어려운 이름은 토론하기도 어렵다.
- 예 : private Date genymdhms; | private Date generationTimestamp;
검색하기 쉬운 이름음 사용하라
- 문자 하나를 사용하는 이름과 상수는 검색하기 어렵다.
- MAX_CLASSES_PER_STUDENT는 찾기 쉽지만, 숫자 7은 찾기 어렵다. 7이 들어가는 파일, 수식이 모두 검색되기 때문에.
- 무조건 짧은 이름이 긴 이름보다 좋은 것은 아니다.
- 검색하기 쉬운 이름이 상수보다 좋다. 예) 5 대신 WORK_DAYS_PER_WEEK
- 간단한 메서드에서 로컬 변수만 한 문자를 사용할 수 있다.
- 이름 길이는 범위 크기에 비례해야 한다.
인코딩을 피하라(변수에 추가 정보를 붙이지 말 것)
- 헝가리식 표기법
- 변수명에 해당 변수의 타입(int, String)을 적지 마라.
- 인터페이스와 구현 클래스
- 인터페이스와 구현 클래스가 나뉠경우, 구현 클래스에 인코딩하라.
예) 인터페이스 : ShapeFactory
구현 클래스 : ShapeFactoryImpl
- 인터페이스와 구현 클래스가 나뉠경우, 구현 클래스에 인코딩하라.
자신의 기억력을 자랑하지 마라
- 독자가 변수 이름을 자신이 아는 이름으로 한번 더 변환해야 한다면, 바람직하지 못한 이름이다.
- 똑똑한 프로그래머와 전문가 프로그래머의 차이는 "명료함" 이다. 전문가 프로그래머는 남들이 이해하는 코드를 내놓는다.
'Book > Clean Code' 카테고리의 다른 글
Clean Code - 깨끗한 코드 (1) | 2023.12.20 |
---|