의미있는 이름
우리는 개발을 하면서 여러 파일, 폴더, 패키지 등등에 이름을 붙이는 일을 많이 하게된다. 이름을 잘 지으면 여러가지로 장점이 많은데 이번 장에서는 이름을 잘 짓는 규칙 몇가지를 소개한다.
의도를 분명히 밝혀라 의도가 분명한 이름은 정말 중요하다. 변수나 함수, 클래스들의 이름은 다음의 굵직한 질문에 모두 답해야한다.
변수나 함수, 클래스들의 존재 이유는? 수행하는 기능은? 사용 방법은? 따로 주석이 필요하다면 의도를 분명히 드러내지 못했다는 말이다.
int d; // 경과 시간 보다는
int elapsedTimeDays; 가 좀 더 의도가 정확히 드러나는 이름이다.
그릇된 정보는 피하라 프로그래머는 코드에 그릇된 정보를 남겨서는 안된다. 특히 소문자 L 이나 대문자 O 같이 숫자 1과 숫자 0 으로 혼돈을 줄만한 변수 명은 피하도록 한다.
의미 있게 구분하라 컴파일러를 통과할지라도 연속된 숫자를 덧붙이거나 불용어를 추가하는 방식은 적절하지 못하다.
// 적절하지 못한 방식 int a1; int a2; int a3; 또한 Product라는 클래스가 있을 때 또 다른 클래스를 ProductInfo, ProductData라 명명하면 개념을 구분하지 않은 채 이름만 달리하는 경우가 된다.
MoneyAmount는 Money와 구분이 되지 않는다.
발음하기 쉬운 이름을 사용하라 class DtaRcrd102 { ... } 과
class Customer { ... } Customer클래스가 의사소통을 할 때 더욱 지적인 대화를 가능하게 만들어준다.
검색하기 쉬운 이름을 사용하라 MAX_DAY 는 IDE의 검색으로 찾기 수월하지만
숫자 7 의 경우는 숫자 7이 들어간 전부가 검색되기 때문에 원하는 검색 결과를 얻기 힘들다.
상수나 변수를 여러 군대에서 사용한다면 검색하기 쉬운 이름이 좋다. 이름 길이는 범위 크기에 비례해야한다
인코딩을 피하라 요즘은 컴파일러가 타입을 기억하고 강제하기 때문에 예전 프로그램 방식처럼 변수명에 해당 변수의 타입을 적어주지 않아도 된다. 이제는 맴버 변수에 m_이라는 접두어를 붙일 필요도 없다 인터페이스와 구현 클래스의 경우는 인코딩이 필요하다 인터페이스 이름에 접두어를 사용하기 보다는 구현 클래스 이름에 인코딩 하도록하자.
자신의 기억력을 자랑하지 마라 루프에서 반복 횟수를 세는 변수 i,j,k는 괜찮다. 클래스 이름과 객체 이름은 명사나 명사구가 적합하다. Customer, WikiPage 등등 단, Manager, Data, Info 등과 같은 단어는 피하고 동사는 사용하지 않는다. 메서드 이름은 동사나 동사구가 적합하다. postPayment, deletePage 등 접근자, 변경자, 조건자는 javabean 표준에 따라 get, set, is를 붙인다.
기발한 이름은 피하라 Abort() 대신 eatMyShort()와 같은 특정 문화에서만 사용하는 농담은 피하라. 의도를 분명하고 솔직하게 표현하라.
한 개념에 한 단어를 사용하라 같은 메서드를 클래스마다 fetct, retrieve, get으로 제각각 부르면 혼란스럽다. 동일 코드 기반에 controller, manager, driver를 섞어 쓰지 않도록 한다. 일관성 있는 어휘를 사용해 코드를 작성한다.
말장난을 하지 마라 한 단어를 두가지 목적으로 사용하지 않도록 한다. 다른 개념에 같은 단어를 사용한다면 그건 말장난에 불과하다.
해법 영역에서 가져온 이름을 사용하라 코드를 읽는 사람도 프로그래머라는 사실을 명심한다. 때문에 전산 용어, 알고리즘 이름, 패턴이름, 수학 용어등을 사용해도 괜찮다.
문제 영역에서 가져온 이름을 사용하라 적절한 프로그래머 용어가 없다면 문제 영역에서 이름을 가져온다.
의미 있는 맥락을 추가하라 클래스, 함수, 이름 공간에 맥락을 부여한다.
모든 방법이 실패하면 마지막 수단으로 접두어를 붙인다.
코드의 맥락을 개선하면 함수를 쪼개기가 쉬워지는 장점이 있다.
불필요한 맥락을 없애라 일반적으로 짧은 이름이 긴 이름보다 좋다. 단, 의미가 분명한 경우에 한해서다.
accountAddress와 customerAddress는 Address 클래스 인스턴스로는 좋은 이름이다. 하지만 accountAddress와 customerAddress는 클래스 이름으로는 적합하지 못하다. 마치면서 좋은 이름을 선택하는 능력은 교육의 문제이다. 이름을 바꿨다고 누군가 질책하더라도 코드를 개선하려는 노력을 중단해서는 안된다.
Last updated