사소할 수 있지만 개발자가 가장 힘들어 하는 것, 가장 신경 쓰는 것이 바로 이름 짓는 것이다. 이름 짓는 것 하나로 코드의 가독성을 결정 지을 수도 있다. Clean Code에 나와 있는 이름 짓는 방법을 정리해본다.

의도를 분명히 밝혀라

변수나 함수, 클래스 이름은 다음의 질문에 모두 답할 수 있어야된다.

  • 변수(혹은 함수나 클래스) 존재 이유

  • 수행 기능

  • 사용 방법

만약 주석이 필요하다면 의도를 분명히 드러내지 못한 것이다. 아래 두 코드는 같은 내용임에도 코드의 의도를 쉽게 이해할 수 있게된다.

public List<int[]> getThem() {
    List<int[]> list1 = new ArrayList<int[]>();
    for (int[] x : theList) 
    if (x[0] == 4)
        list1.add(x); 
    return list1;
}

public List<Cell> getFlaggedCells() {
    List<Cell> flaggedCells = new ArrayList<Cell>(); 
    for (Cell cell : gameBoard)
    if (cell.isFlagged()) 
        flaggedCells.add(cell);
    return flaggedCells; 
}

후자의 코드를 보면 지뢰 찾기 코드의 일부임을 쉽게 파악할 수 있다.

그릇된 정보를 피하라

변수명에 잘못된 정보를 남기면 안된다. 예를들어, 실제로 List자료형이 아닌데 accountList라는 변수명을 사용하는 경우가 있다. 또한 개발자에게 혼란을 줄 수 있는 내용도 담으면 안된다. 직각삼각형의 빗변(hypotenuse)을 구현할 때 hp라는 변수는 좋지않다. 유닉스 플랫폼이나 유닉스 변종을 가리키는 이름이기 때문이다. 또한 서로 흡사한 이름을 사용하여 혼란을 야기해서도 안된다.

의미 있게 구분하라

변수들에게 연속된 숫자(a1, a2, … , aN)를 덧붙이거나 불용어를 추가하는 방식은 적절하지 못하다. Product라는 클래스가 있는데 ProductInfo 혹은 ProductData가 있는 경우가 대표적인 잘못된 예이다. 이름만으로도 개발자가 어떤 변수, 클래스, 함수를 사용해야되는지 파악할 수 있도록 해야된다.

발음하기 쉬운 이름을 사용하라

발음하기 어려운 이름은 토론하기도 어렵다. ymdhms보다 timestamp가 훨씬 의미도 있고 발음하기 쉽다.

검색하기 쉬운 이름을 사용하라

MAX_CLASSES_PER_STUDENT가 숫자 7과 e라는 변수명보다 훨씬 grep으로 찾기 쉽다. 이런 관점에서 긴 이름이 짧은 이름보다 좋다.

인코딩을 피하라

변수명에 유형이나 범위까지 넣으면 이름을 해독하기 어려워진다. 옛날에는 부실한 IDE와 이름 길이가 제한되어 있어서 어쩔 수 없이 헝가리식 표기법과 멤버 변수 접두어를 사용했다. 지금은 그럴 필요가 없다. 인터페이스 클래스의 경우는 굳이 인코딩을 해야된다면 인터페이스가 아닌 구현 클래스에 하는것이 좋다. IShapeFactory와 ShapeFactory 보다는 ShapeFactory와 CShapeFactory가 좋다.

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

코드를 읽으면서 변수 이름을 자신이 아는 다른 이름으로 변환해야 된다면 그 변수 이름은 바람직하지 못하다. 변수명은 명료함이 최고다.

  • 클래스 이름: 클래스 이름과 객체 이름은 명사나 명사구가 적합하다. 단, Manager, Processor, Data, Info 등과 같은 단어는 피한다.

  • 메서드 이름: 동사나 동사구가 적합하다. 접근자, 변경자 조건자는 javabean 표준에 따라 값 앞에 get, set, is를 붙인다.

  • 생성자 오버로딩을 할 때는 정적 팩토리 메서드를 사용한다. 정적 팩토리 메서드의 네이밍은 링크를 참고한다.

기발한 이름은 피하라

특정 문화에서만 사용하는 농담은 피하는 편이 좋다. 재미난 이름보다는 명료한 이름을 선택하고, 의도를 분명하고 솔직하게 표현하라.

한 개념에 한 단어를 사용하라

추상적인 개념 하나에 단어 하나를 선택해서 이것만 사용해야된다. 똑같은 메서드를 클래스마다 fetch, retrive, get으로 제각각 부르면 혼란스럽다. 또한 동일 코드 기반에 controller, manager, driver를 섞어 쓰면 혼란스럽다.

말장난을 하지 마라

한 단어를 두 가지 목적으로 사용하지 마라. add라는 메서드를 기존 값 두 개를 더하거나 이어서 새로운 값을 만든다고 했을 때, 집합에 값 하나를 추가하는 메서드를 add로 짓는 것은 말장난에 불과하다. insert나 append라는 이름이 적당하다.

해법 영역에서 가져온 이름을 사용하라

모든 이름을 문제 영역(domain)에서 가져오는 정책은 현명하지 못하다. 코드를 읽는 사람도 프로그래머이므로 기술 개념에는 기술 이름이 가장 적합한 선택이다.

문제 영역에서 가져온 이름을 사용하라

적절한 프로그래머 용어가 없다면 문제 영역에서 이름을 가져온다. 문제 영역 개념과 관련이 깊은 코드라면 문제 영역에서 이름을 가져와야 한다.

의미 있는 맥락을 추가하라

스스로 의미가 분명한 이름은 많지 않다. 그래서 클래스, 함수, 이름 공간에 넣어 맥락을 부여한다. 모든 방법이 실패하면 마지막 수단으로 접두어를 붙인다. state만 보고는 주소 일부라는 사실을 알아채기 힘들다. 따라서 접두어를 추가해 addrState라 쓰면 맥락이 좀 더 분명해진다. 가장 좋은 방법은 Address라는 클래스를 생성하고 그의 멤버 변수로 state를 두는 것이다.

불필요한 맥락을 없애라

고급 휘발유 충전소(Gas Station Deluxe)라는 애플리케이션을 짠다고 가정하자. 이 애플리케이션의 회계 모듈에 MailingAddress 클래스를 추가하면서 클래스 이름을 GSDAccountAddress로 바꾸는 것은 바람직하지 못하다. 나중에 다른 고객 관리 프로그램에서 고객 주소가 필요할 수 있다. 일반적으로는 짧은 이름이 긴 이름보다 좋다. 하지만 의미가 분명한 경우에 한해서다. accountAddress와 customerAddress는 Address클래스의 인스턴스로는 좋지만, 클래스 이름으로는 적합하지 않다.

댓글남기기