클린 코드 : 의미 있는 이름 (1)

의도를 분명히 밝혀라

• 좋은 이름을 지으려면 시간이 많이 걸리지만, 좋은 이름으로 절약하는 시간이 훨씬 더 많다.
• 이름은 대상의 존재 이유, 수행 기능, 사용 방법을 드러내야 한다.
• 주석이 필요하다면 의도를 분명히 드러내지 못했다는 말이다.
• 단순히 이름만 고쳐도 함수가 하는 일을 이해하기 쉽다.

그릇된 정보를 피하라

• 그릇된 단서를 남기지 않는다.

  • 널리 쓰이는 의미가 있는 단어를 사용하지 않는다.

    • 예시 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
    
    

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

• 독자가 변수 이름을 자신이 아는 이름으로 한번 더 변환해야 한다면, 바람직하지 못한 이름이다.
• 똑똑한 프로그래머와 전문가 프로그래머의 차이는 "명료함" 이다. 전문가 프로그래머는 남들이 이해하는 코드를 내놓는다.