[클린 코드] 챕터2 의미 있는 이름1

6 분 소요

2.1 들어가면서

이름은 어디나 쓰인다. 변수에도, 함수에도, 인수와 클래스에도, 패키지에도 이름을 붙인다. 파일에도, 폴더에도 이름을 붙인다. 여기저기 많이 사용하는 만큼 이름을 잘지으면 편하다.

이 장에서는 이름을 잘 짓는 간단한 규칙 몇 가지를 소개한다.

2.2 의도를 분명히 밝혀라

의도가 분명하게 이름을 지으라고 말하기는 쉽다. 여기서는 의도가 분명한 이름이 정말로 중요하다는 사실을 거듭 강조한다. 좋은 이름을 지으려면 시간이 걸리지만 좋은 이름으로 절약하는 시간이 훨씬 더 많다.

변수나 함수나 클래스 이름은 다음과 같은 굵직한 질문에 모두 답해야한다.

변수,함수, 클래스의 존재 이유는?

수행 기능은?

사용 방법은?

따로 주석이 필요하다면 의도를 분명히 드러내지 못했다는 소리다.

int d; //경과 시간(단위: 날짜 수)

이름 d는 아무런 의미가 드러나지 않는다. 경과 시간이나 날짜 수라는 느낌이 안든다.

측정하려는 값과 단위를 표현하는 이름이 필요하다.

int elapsedTimeInDay;
int daysSinceCreation;
int daySinceModification;
int fileAgeInday

의도가 드러나는 이름을 사용하면 코드 이해와 변경이 쉬워진다.

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

코드가 하는 일을 짐작하기 어렵다. 복잡한 문장은 없다. 공백과 들여쓰기도 적장하다. 변수는 3개 상수는 2개뿐이다. 문제는 코드의 단순성이 아니라 코드의 함축성이다. 다시말해, 코드 맥락이 코드 자체에 명시적으로 드러나지 않는다. 위 코드는 독자가 다음 정보를 안다고 명시적으로 가정한다.

theList에 무엇이 들었는가?
theList에서 0번째 값이 어째서 중요한가?
값 4는 무슨 의미인가?
함수가 반환하는 리스트 list1을 어떻게 사용하는가?

위 함수를 지뢰 찾기 게임이라고 생각하자

배열에서 0번째 값은 칸 상태를 뜻한다. 값 4는 깃발이 꽂힌 상태를 가리킨다. 각 개념에 이름만 붙여도 코드가 상당히 나아진다.

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

위에서 보듯이 코드의 단순성은 변하지 않았다. 그런데도 코드는 더욱 명확해졌다.

단순히 이름만 고쳤는데 함수가 하는 일을 이해하기 쉬워졌다. 바로 이것이 좋은 이름이 주는 위력이다.

2.3 그릇된 정보를 피하라

프로그래머는 코드에 그릇된 단서를 남겨서는 안 된다. 그릇된 단서는 코드 의미를 흐린다.

여러 데이터를 묶을 때 실제로 List가 아니라면, dataList라고 명명하지 않는다. 프로그레머에게 List라는 단어는 특수한 의미다. 실제 List가 아니라면 프로그래머에게 그릇된 정보를 제공하는 셈이다.

서로 흡사한 이름을 사용하지 않도록 주의한다. 한 모듈에서 XYZControllerHandling, XYZControllerStondling라는 이름을 사용하면 확실하게 구별할 수 있겠는가? 겁나 비슷하다.

유사한 개념은 유사한 표기법을 사용한다. 이것도 정보다. 일관성이 떨어지는 표기법은 그릇된 정보다.

우리는 IED에서 제공하는 자동완성 기능을 사용한다. 대부분의 사람들은 객체에 달린 상세한 주석이나. 클래스가 제공하는 메소드 목록을 살펴보지 않고 이름만 보고서 객체를 선택한다. 자동완성을 보면 알겠지만 잘명명된 이름은 굉장히 유용하다.

이름으로 그릇된 정보를 제공하는 진짜 끔찍한 예가 소문자 L이나 대문자 O변수다. 두 변수를 한꺼번에 사용하면 더욱 끔찍해진다.

int a = 1;
if(0==l){
 a=01;
}else{
 l=01;
}

어느경우는 글꼴을 바꿔 차이를 들어낼려하지만 미래의 개발자들에게 이 사실을 문서나 구전으로 알려야한다. 그냥 이름만 바꾸면 문제가 해결된다. 일거리를 만들 필요가없다.

2.4 의미 있게 구분하라

컴파일러나 인터프리터만 통과하려는 생각으로 코드를 구현하는 프로그래머는 스스로 문제를 일으킨다. 예를 들어, 동일한 범위 안에서는 다른 두 개념에 같은 이름을 사용하지 못한다. 그래서 프로그래머가 한쪽 이름을 마음대로 바꾸고픈 유혹에 빠진다.

ex) int array, int arrayk

컴파일러를 통과할지라도 연속된 숫자를 덧붙이거나 불용어(noise word)를 추가하는 방식은 적절하지 못하다. 이름이 달라야 한다면 의미도 달라져야 한다.

연속적인 숫자를 덧붙인 이름(a1,a2,a3…)은 의도적인 이름과 정반대다. 그릇된 정보를 제공하는 이름도 아니다. 아무런 정보를 제공하지 못하는 이름이다. 저자 의도가 전혀 드러나지 않는다. 다음 코드에서 무엇을 얻을 수 있는가.

public static void copyChars(char a1[], char a2[]){
 for(int i = 0; i < a1.length; i++){
  a2[i] = a1[i]
 }
}

함수 인수 이름으로 source와 destination을 사용한다면 코드를 읽기가 훨씬 더 쉬워진다.

불용어를 추가한 이름 역시 아무런 정보도 제공하지 못한다. Product라는 클래스가 있다고 가정하자. 다른 클래스를 ProductInfo 혹은 ProductData라 부른다면 개념을 구분하지 않은 채 이름만 달리한 경우다. Info나 Data는 a,an,the와 마찬가지로 의미가 불분명한 불용어다.

불용어는 중복이다. 변수 이름에 variable이라는 단어는 단연코 금물이다. 표 이름에 table이라는 단어도 마찬가지이다. nameString이 name보다 뭐가 나은가? name이 부동소수가 될 가능성이 있는가? 만약 그렇다면 “그릇된 정보를 피하라”는 규칙을 위반한다.

코드를 읽다가 Customer라는 클래스와 CustomerObject라는 클래스를 발견했다면 차이를 알겠는가? 고객 급여 이력을 찾을려면 어느 클래스를 뒤져야 빠를까?

다음의 함수명을 보자

getActiveAccount();
getActiveAccounts();
getActiveAccountInfo();

이 프로젝트에 참여한 프로그래머는 어느 함수를 호출할지 어떻게 알까?

명확한 관례가 없다면, 변수 moneyAmount는 money와 구분이 안 된다. customerInfo는 customer와, accountData는 account와, theMessage는 message와 구분이 안 된다.
“읽는 사람이 차이를 알도록 이름을 지어라.”

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

사람들은 단어에 능숙하다. 말을 처리하려고 발달한 두뇌를 활용하지 않는다면 안타까운 손해다. 그러므로 발음하기 쉬운 이름을 선택한다. 형편없는 이름을 말하는것은 정말 우수꽝스럽다.

genymdhms(generate, date, year, month, day, hour, minute, second)라는 단어를 사용하는 회사가있었는데 필자는 이단어를 “젠 야 무다 힘즈” 라고 읽었다. 새로운 개발자가오면 이 이름을 설명 해주고 발음도 알려주어야 했다.

다음 두 예제를 비교해보자.

class DtaRcrd102{
 private Date genymdhms;
 private Date modymdhms;
 private final String pszqint = "102";
}

class Customer{
 private Date generationTimestamp;
 private Date modificationTimestamp;
 private final String recordId = "102";
}

둘째 코드는 지적인 대화가 가능해진다.

“마이크, 이 레코드 좀 보세요. Generation Timestamp 값이 내일 날짜 입니다! 어떻게 이런 일이 벌어지죠?”

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

문자 하나를 사용하는 이름과 상수는 텍스트 코드에서 쉽게 눈에 띄지 않는다는 문제점이 있다.

MAX_CLASSES_PER_STUDENT는 찾기 쉽지만 숫자 7은 은근히 까다롭다. 7이 들어간 파일 이름이나 수식이 모두 검색되기 때문이다. 마찬가지로 e라는 문자도 변수 이름으로 적합하지 못하다. 검색이 어렵기 때문이다.

이런 관점에서 긴 이름이 짧은 이름보다 낫다. 검색하기 쉬운 이름이 상수보다 낫다.

다음 두 예제를 비교해보자.

for(int j = 0; j<34; j++){
 s += (t[j]*4)/5;
}

int realDaysPerIdealDay = 4;
const int NUMBER_OF_TASKS= 34;
const int WORK_DAYS_PER_WEEK = 5;
int sum = 0;
for(int j = 0; j < NUMBER_OF_TASKS; j++){
 int realTaskDay = taskEstimate[j] * realDaysPerIdealDay;
 int realTaskWeeks = (realDays / WORK_DAYS_PER_WEEK);
 sum += realTaskWeeks;
}

이름을 의미 있게 지으면 함수가 길어진다. 하지만 WORK_DAYS_PER_WEEK 을 찾기가 얼마나 쉬운지 생각해보라. 그냥 5를 사용하면 5가 들어가는 이름을 모두 찾은 후 의미를 분석해 원하는 상수를 가려내야 하리라.

2.7 인코딩을 피하라

이름에 인코딩할 정보는 아주 많다. 유형이나 범위 정보까지 인코딩에 넣으면 그만큼 이름을 해독하기 어려워진다. 새로운 개발자가 익힐 코드 양은 상당히 많다. 여기다 인코딩 ‘언어’까지 익히라는 요구는 비합리적이다. 인코딩한 이름은 거의가 발음하기 어려우며 오타가 생기기도 쉽다.

헝가리식 표기법

과거에는 컴파일러가 타입을 점검하지 않았으므로 프로그래머는 타입을 기억할 단서가 필요했다.

헝가리식 표기는 변수 및 함수의 이름 인자 앞에 데이터 타입을 명시하는 코딩 규칙를 말한다.

아이러니하게도, 코드를 단번에 파악하기 힘들어진다.

예를들어

n : Count 변수

d : 두 값의 차이를 담는 변수

us : 안전이 확인되지 않은 변수(UnSafe)

s : 안전이 확인된 변수(Safe)

Locked : 함수의 접미사. 스레드 안전하지 않은 함수기 때문에 사용하기 전에 Lock을 잡아야 한다 안드로이드에서 사용된다.

int sValue = usValue; // Unsafe 값을 Safe 변수에 바로 넣었다. 양변의 의미가 다르므로 문제가 있는 코드

sValue = sCheck(usValue); // us값을 체크해서 s로 바꿔주는 함수 sCheck를 거쳤다. 양변이 모두 s이므로 문제없는 코드

sValue = sCheckLocked(usValue); // 의미는 맞지만 Locked 함수를 쓰기 전에 락을 걸지 않았다. 멀티스레드에서 동작시 문제가 생길 수 있다.

현제는 IDE가 코드를 컴파일하지 않고도 타입 오류를 감지할 정도로 발전했다. 따라서 이제는 헝가리식 표기법이나 기타의 인코딩 방식은 오히려 방해가 될뿐이다. 변수, 함수, 클래스 이름이나 타입을 바꾸는 것이 어려워지며, 읽기도 어려워진다.

멤버 변수 접두어

이제는 멤버 변수에 m_이라는 접두어를 붙일 필요도 없다. 클래스와 함수는 접두어가 필요없을 정도로 작아야 마땅하다.

public class Part{
 private String m_dsc;
 void setName(String name){
  m_dsc = name;
 }
}

public class Part{
 String description;
 void setDescription(String description){
  this.description = description;
 }
}

게다가 사람들은 접두어(접미어)를 무시하고 이름을 해독하는 방식을 재빨리 익힌다. 코드를 읽을수록 접두어는 관심 밖으로 밀려난다. 결국 접두어는 옛날에 작성한 구닥다리 코드라는 징표가 되어버린다.

인터페이스 클래스와 구현 클래스

때로는 인코딩이 필요한 경우가 있다. 예를 들어, 도형을 생성하는 추상 팩토리를 구현한다고 가정하자. 이 팩토리는 인터페이스이다. 구현은 실제 클래스에서 한다. 그렇다면 두 클래스의 이름을 어떻게 지어야 좋을까? IShapeFactory와 ShapeFactory?

개인적으로 인터페이스 이름은 접두어를 붙이지 않는 편이 낫다고 생각한다. I는 주의를 흩트리고 과도한 정보를 제공한다. 그래서 인터페이스 클래스 이름과 구현 클래스 이름 중 하나를 인코딩해야 한다면 구현 클래스 이름을 택하겠다. ShapeFactoryImp가 IShapeFactory보다 낫다.

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

독자가 코드를 읽으면서 변수 이름을 자신이 아는 이름으로 변환해야 한다면 그 변수 이름은 바람직하지 못하다. 이는 일반적으로 문제 영역이나 해법 영역에서 사용하지 않는 이름을 선택했기 때문에 생기는 문제다.

문자 하나를 사용하는 변수 이름은 문제가 있다. 루프에서 반복 횟수를 세는 변수 i,j,k는 괜찮다.(l빼고) 루프 범위가 아주 작고 다른 이름과 충돌하지 않을때만!

그 외에는 대부분 적절하지 못하다. 독자가 실제 개념으로 변환해야 하기때문이다.

r이라는 변수가 호스트와 프로토콜을 제외한 소문자URL이라는 사실을 언제나 기억한다면 확실히 똑똑한 프로그래머다. 하지만 전문가 프로그래머와 다른 점 하나는 전문가 프로그래머는 명료함이 최고라는 사실을 이해한다. 전문가 프로그래머는 자신의 능력을 남들이 이해하는 코드로 만들기위해 사용한다.

2.9 클래스 이름

클래스 이름과 객체 이름은 명사나 명사구가 적합하다. Customer, WikiPage, Account등이 좋은 예다.

Manager, Processor, Data, Info등과 같은 단어는 피하고, 동사는 사용하지 않는다.

참조

로버트 C. 마틴, 『Clean Code 클린 코드』, 박재호, 이해영 옮김, 케이앤피북스(2010), P54-63.

Twitter Facebook LinkedIn

Jusung Kim