[Clean Code] 4장. 주석

나쁜 코드에 주석을 달지 마라. 새로 짜라.

— 브라이언 W. 커니핸, P. J. 플라우거

 

- 프로그래밍 언어를 치밀하게 사용해 의도를 표현할 능력이 있다면, 주석은 거의 필요하지 않으리라.
- 우리는 코드로 의도를 표현하지 못해, 그러니까 실패를 만회하기 위해 주석을 사용한다.
- 때때로 주석 없이는 자신을 표현할 방법을 찾지 못해 할 수 없이 주석을 사용한다.
- 그러므로 주석이 필요한 상황에 처하면 곰곰이 생각하기 바란다. 상황을 역전해 코드로 의도를 표현할 방법은 없을까? 코드로 의도를 표현할 때마다 스스로를 칭찬해준다.
- 주석은 오래될수록 코드에서 멀어진다. 이유는 단순하다. 프로그래머들이 주석을 유지하고 보수하기란 현실적으로 불가능하니까.
- 나라면 코드를 깔끔하게 정리하고 표현력을 강화하는 방향으로, 그래서 애초에 주석이 필요 없는 방향으로 에너지를 쏟겠다.
- 부정확한 주석은 아예 없는 주석보다 훨씬 더 나쁘다.
- 코드만이 자기가 하는 일을 진실되게 말한다. 코드만이 정확한 정보를 제공하는 유일한 출처다. 그러므로 우리는 주석을 가능한 줄이도록 꾸준히 노력해야 한다.

 

우리가 주석을 다는 이유는 코드로 의도를 모두 표현하지 못했기 때문에 그러한 충동이 드는 것이고, 주석을 작성하게 되면 코드를 끊임없이 유지보수하는 과정에서 제대로 관리되지 못할 가능성이 커진다.

따라서 전체적인 코드가 주석으로 인해 더욱 지저분해질 수 있기 때문에 코드의 표현력을 강화하여 정확한 정보를 제공하는 것이 더욱 좋다.

 

주석을 달고 싶다는 충동이 들었다면, 그 생각을 코드로 표현할 수 있는 방법은 없을까 다시 한번 생각해보자!

 

주석은 나쁜 코드를 보완하지 못한다

• 코드에 주석을 추가하는 일반적인 이유는 코드 품질이 나쁘기 때문
• 하지만 코드 품질이 나쁠 때, 주석을 달아야겠다는 생각보다 코드를 정리해야겠다는 생각을 할 것!

표현력이 풍부하고 깔끔하며 주석이 거의 없는 코드가, 복잡하고 어수선하며 주석이 많이 달린 코드보다 훨씬 좋다. 자신이 저지른 난장판을 주석으로 설명하려 애쓰는 대신에 그 난장판을 깨끗이 치우는 데 시간을 보내라!

 

코드로 의도를 표현하기

• 분명히 코드만으로 의도를 설명하기 어려운 상황이 존재하지만 조금만 더 생각하면 대다수의 의도를 표현할 수 있음
• 많은 경우 주석으로 달려는 설명을 함수로 만들어 표현해도 충분!

if ((employee.flags & HOURLY_FLAG) && (employee.age > 65))
// vs.
if (employee.isEligibleForFullBenefits())

 

좋은 주석

어떤 주석은 필요하거나 유익하다. 하지만 명심하기 바란다. 정말로 좋은 주석은, 주석을 달지 않을 방법을 찾아낸 주석이라는 사실을!

법적인 주석

• 때로 회사가 정립한 구현 표준에 맞춰 법적인 이유로 특정 주석을 넣어야 할 때가 있음

→ 저작권 정보, 소유권 정보 등

• 표준 라이선스나 외부 문서 참조하기

 

정보를 제공하는 주석

• 때로 기본적인 정보를 주석으로 제공하면 편리함

// 테스트 중인 Resoponder 인스턴스를 반환
protected abstract Responder responderInstance();

// kk:mm:ss EEE, MMM dd, yyyy 형식이다
Pattern timeMatcher = Patter.compile(“\\d*:\\d*:\\d* \\w*, \\w* \\d*, \\d*”);

→ 하지만 두 경우 모두 함수 이름에 정보를 담거나(responderBeingTested) 시각과 날짜를 변환하는 클래스를 만들어 코드를 옮기면 더 깔끔해지며 주석이 필요 없어짐

 

의도를 설명하는 주석

• 때로는 주석을 통해 그렇게 코드를 작성한 결정에 깔린 의도를 설명함

 

의미를 명료하게 밝히는 주석

• 모호한 인수나 반환값에 대해 읽기 좋게 표현하면 이해하기가 쉬워짐
• 인수나 반환값 자체를 명확하게 만들면 더 좋겠지만, 인수나 반환값이 표준 라이브러리나 변경하지 못하는 코드인 경우 의미를 명료하게 밝히는 주석이 유용함
• 하지만 이 때에도 잘못된 주석을 달 가능성이 있으며 주석은 올바른지 검증하기 어려우므로 더 나은 방법을 고민 후 주의하여 작성하기

public void testCompareTo() throws Exception {
	WikiPagePath a = PathParser.parse(“PageA”);
	WikiPagePath b = PathParser.parse(“PageB”);
	…

	assertTrue(a.compareTo(a) == 0);	// a == a
	assertTrue(a.compareTo(b) != 0);	// a != b
	…
}

 

결과를 경고하는 주석

• 다른 프로그래머에게 결과를 경고할 목적으로 사용

 

TODO 주석

• ‘앞으로 할 일’을 // TODO 로 남겨두면 편함

 

• 프로그래머가 필요하다 여기지만 당장 구현하기 어려운 업무
• 더 이상 필요 없는 기능을 삭제하라는 알림
• 누군가에게 문제를 봐 달라는 요청
• 더 좋은 이름을 떠올려달라는 부탁
• 앞으로 발생할 이벤트에 맞춰 코드를 고치라는 주의 등

 

• 하지만 시스템에 나쁜 코드를 남겨 두는 핑계가 되어서는 안 됨
• 주기적으로 TODO 주석을 점검하여 없애도 좋은 주석은 없애기!

 

중요성을 강조하는 주석

• 자칫 대수롭지 않다고 여겨질 뭔가의 중요성을 강조하기 위해 사용

// 예.
String listItemContent = match.group(3).trim();
// 여기서 trim은 정말 중요하다. trim 함수는 문자열에서 시작 공백을 제거한다
// 문자열에 시작 공백이 있으면 다른 문자열로 인식되기 때문이다
…

 

공개 API에서 Javadocs

• 설명이 잘 된 공개 API는 유용함
• 표준 자바 라이브러리에서 사용한 Javadocs 가 좋은 예
• 공개 API를 구현한다면 반드시 훌륭한 Javadocs를 작성
• 하지만 Javadocs 도 여느 주석과 마찬가지로 독자를 오도하거나, 잘못 위치하거나, 그릇된 정보를 전달할 가능성이 존재하므로 주의해서 작성하기

 

나쁜 주석

• 대다수의 주석이 나쁜 주석에 속함

 

주절거리는 주석

특별한 이유 없이 의무감으로 혹은 프로세스에서 하라고 하니까 마지못해 주석을 단다면 전적으로 시간낭비다. 주석을 달기로 결정했다면 충분한 시간을 들여 최고의 주석을 달도록 노력한다.

• 주석을 읽었을 때 이해가 되지 않아서 다른 모듈을 뒤져야 하는 주석은 독자와 제대로 소통하지 못하는 주석

 

같은 이야기를 중복하는 주석

• 주석이 코드보다 더 많은 정보를 제공하지 못하고 코드 내용을 중복하는 것은 코드를 지저분하게 만들고 정신없게 만듬

// 목록 4-2 (p. 77) 일부
/**
	* 이 컴포넌트의 프로세서 지연값
	*/
protected int backgroundProcessorDelay = -1;

/**
	* 이 컴포넌트를 지원하기 위한 생명주기 이벤트
	*/
protected LifecycleSupport lifecycle = new LifecycleSupport(this);

/**
	* 이 컴포넌트를 위한 컨테이너 이벤트 Listener
	*/
protected ArrayList listeners = new ArrayList();
...

 

오해할 여지가 있는 주석

• 의도는 좋으나 딱 맞을 정도로 엄밀하게 주석을 달지 못하면 ‘살짝 잘못된 정보’로 인해 골머리를 앓을 수 있음

// 목록 4-1 (p.77) : '같은 이야기를 중복하는 주석'의 예제이기도 함
// this.closed 가 true 일 때 반환되는 유틸리티 메서드다.
// 타임아웃에 도달하면 예외를 던진다.
public synchronized void waitForClose(final long timeoutMillis) throws Exception {
	if(!closed) {
		wait(timeoutMillis);
		if(!closed)
			throw new Exception("~~");
	}
}

→ this.closed 가 true 로 변하는 순간에는 메서드가 반환되지 않음

→ this.closed 가 true 여야 메서드는 반환되며, 그게 아니라면 무조건 타임아웃을 기다렸다가 그래도 this.closed 가 true 가 아니면 예외를 던짐

 

의무적으로 다는 주석

• 모든 함수에 Javadocs 를 달거나 모든 변수에 주석을 달아야 한다는 규칙은 오히려 코드를 헷갈리게 만들고, 거짓말할 가능성을 높이며, 잘못된 정보를 제공할 여지를 만듬

 

이력을 기록하는 주석

• 예전에는 소스 코드 관리 시스템이 없었기 때문에 모듈 첫머리에 변경 이력을 기록하고 관리했으나 이제는 그럴필요가 없기에 제거하는 것이 좋음

 

있으나 마나 한 주석

• 너무 당연한 사실을 언급하여 새로운 정보를 제공하지 못하는 주석은 개발자가 주석을 무시하게 만들며 결국 코드가 바뀌게 되면 주석은 거짓말로 변하게 됨
• 있으나 마나 한 주석을 달기 보다 코드를 정리할 것

 

무서운 잡음

• 단지 문서를 제공해야 한다는 욕심이 잡음이 될 수 있음

/** The name. */
private String name;

/** The version. */
private String version;

/** The licenceName. */
private String licenceName;

/** The version. */
private String info;

→ 잘라서 붙여넣기 오류를 확인할 수 있음

→ 독자에게 어떤 이익이 있는가?

 

함수나 변수로 표현할 수 있다면 주석을 달지 마라

// 전역 목록 <smodule>에 속하는 모듈이 우리가 속한 하위 시스템에 의존하는가?
if (smodule.getDependSubsystems().contains(subSysMod.getSubSystem()))\

// 주석을 제거하고 수정한 버전
ArrayList moduleDependees = smodule.getDependSubsystems();
String ourSubSystem = subSysMod.getSubSystem();
if (moduleDependees.contains(ourSubSystem))

→ 주석이 필요하지 않도록 코드를 개선하는 것이 좋음

→ 주석이 있는 버전은 읽었을 때 ‘무슨 말이지?’ 싶었는데 주석을 제거하고 코드를 수정한 버전은 코드만 읽어도 이해가 잘 된다!

 

위치를 표시하는 주석

• 소스 파일에서 특정 위치를 표시하는 주석

// Action /////////////////////////

→ 이런 배너 아래에 특정 기능을 모아두면 유용한 경우도 있긴함! (실제로 나도 종종 사용했었다,,ㅎㅎ)

→ 하지만 일반적으로 가독성을 낮추고 남용할 경우 독자가 잡음으로 여기고 무시할 수 있기 때문에 제거하는 것이 좋음

→ 특히 뒷부분의 슬래시(/)는 제거하는 편이 좋음!

 

• 이러한 배너는 너무 자주 사용하지 않는다면 눈에 띄며 주의를 환기함

→ 반드시 필요할 때만, 아주 드물게 사용하기

 

닫는 괄호에 다는 주석

• 때로는 아래와 같이 닫는 괄호에 주석을 달기도 함

// 목록 4-6 (p. 85)
try {
	while ((line = in.readLine()) != null) {
		...
	} // while
	...
} // try

• 중첩이 심하고 장황한 함수라면 의미가 있을지도 모르지만 작고 캡슐화된 함수에는 잡음일 뿐
• 닫는 괄호에 주석을 달아야겠다는 생각이 들면 함수를 줄이려 시도하기

→ 실제로 나도 중첩이 너무 복잡한 경우 각각의 괄호의 역할이 헷갈려서 이렇게 닫는 괄호에 주석을 단 경험이 있다. 하지만 그런 경우는 중첩이 많아 코드가 복잡한 경우였는데 애초에 코드가 복잡하게 보이도록 그냥 둬서는 안되는 것이였다는 생각이 든다.

 

공로를 돌리거나 저자를 표시하는 주석

• 소스 코드 관리 시스템을 사용하면 누가 언제 무엇을 추가했는지 알 수 있음
• 이러한 주석은 코드에 방치되면 점차 부정확하고 쓸모없는 정보가 될 가능성이 큼

 

주석으로 처리한 코드

• 코드를 주석으로 처리해두면 남겨둔 이유가 있다고 판단하고 다른 사람들이 지우기를 주저하게 됨

→ 점차 쓸모 없는 코드로 변함

• 과거에는 주석으로 처리한 코드가 유용했지만 이제는 소스 코드 관리 시스템을 사용하므로 주석으로 처리해서 기억할 필요가 없음

 

HTML 주석

• HTML 주석은 편집기나 IDE 에서 조차 읽기가 어려움
• 만약 Javadocs 와 같은 도구로 주석을 뽑아 웹 페이지에 올리고 싶다면 프로그래머가 주석에 HTML 태그를 다는 것이 아닌 도구가 해결하도록 해야함

 

전역 정보

• 주석을 달아야 한다면 근처에 있는 코드만 기술할 것
• 코드 일부에 다는 주석에 시스템의 전반적인 정보를 기술하지 말 것

→ 다른 부분에서 설정하는 코드에 대한 주석이라면 해당 코드가 변해도 달아둔 주석이 함께 관리된다는 보장이 없음

 

너무 많은 정보

• 주석에 흥미로운 역사나 관련 없는 정보를 장황하게 늘어놓지 말 것

→ 독자에게 불필요한 정보

 

모호한 관계

• 주석과 주석이 설명하는 코드는 둘 사이 관계가 명백해야 함
• 독자가 주석과 코드를 읽었을 때 무슨 의미인지 알 수 없다면 불필요한 주석일 뿐

 

함수 헤더

• 짧은 함수는 긴 설명이 필요하지 않음
• 짧고 한 가지만 수행하며 이름을 잘 붙인 함수가 주석으로 헤더를 추가한 함수보다 좋음

 

비공개 코드에서 Javadocs

• 공개 API 에서는 Javadocs 가 유용하지만 공개하지 않을 코드라면 Javadocs 는 유용하지 않으며 코드를 보기 싫게 만들 뿐