주석

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

주석은 언제나 실패를 의미한다. 코드로 의도를 표현할 방법을 찾지 못해 할 수 없이 주석을 사용한다. 주석은 오래될수록 코드에서 멀어진다. 주석까지 유지보수하기란 현실적으로 불가능하니까. 부정확한 주석은 독자를 현혹하고 오도한다. 코드만이 정확한 정보를 제공하는 유일한 출처다. 그러므로 우리는 주석을 가능한 줄이도록 꾸준히 노력해야 한다.

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

• 표현력이 풍부하고 깔끔하며 주석이 거의 없는 코드가, 복잡하고 어수선하며 주석이 많이 달린 코드보다 훨씬 좋다.

코드로 의도를 표현하라!

• 코드만으로 의도를 설명하기 어려운 경우가 존재한다.
  조금 더 생각하면 코드로 대다수 의도를 표현할 수 있다.

# before
// 직원에게 복지 혜택을 받을 자격이 있는지 검사한다.
if ((employee.flags & HOURLY_FLAG) && employee.age > 65)
# after
if (employee.isEligibleForFullBenefits())

좋은 주석

어떤 주석은 필요하거나 유익하다.

법적인 주석

• 저작권, 소유권 정보 등을 명시한다.
  가능하다면 표준 라이선스나 외부 문서를 참조해도 되겠다.

정보를 제공하는 주석

• 시각과 날짜 형식 등을 직관적으로 표현 가능하다.

의도를 설명하는 주석

• 코드를 결정하게된 의도를 설명한다.

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

• 모호한 인수나 반환값은 그 의미를 좋게 표현하면 이해하기 쉬워진다.
  • ex) assertTrue(a.compareTo(a) == 0); // a == a
• 주석이 옳은지 신뢰할 수 없어 위험하기도 하다.

결과를 경고하는 주석

• 특정 테스트 케이스를 꺼야할 수 있다.
  • ex) @Ignore(“not ready yet”)

TODO 주석

• ‘앞으로 할 일’을 남겨두면 편하다. 프로그래머가 당장 구현하기 어려운 업무를 기술한다.
  • ex) // TODO 이메일 발송 구현
• 어떤 용도이든 시스템에 나쁜 코드를 남겨 놓는 핑계가 되어서는 안된다.
• 요즘 나오는 대다수 IDE는 TODO 주석 전부를 찾아 보여주는 기능을 제공하므로 주석을 잊어버릴 염려는 없다. 그러므로 주기적으로 TODO 주석을 점검해 없애도 괜찮은 주석은 없애라고 권한다.

중요성을 강조하는 주석

• 중요성을 강조하기 위해서도 사용한다.

공개 API에서 Javadocs

• 설명이 잘 된 공개 API는 참으로 유용하고 만족스럽다.
• 독자를 오도하거나, 잘못 위치하거나, 그릇된 정보를 전달할 가능성이 존재하니 유의하여 작성하도록 한다.

나쁜 주석

대다수 주석이 이 범주에 속한다.

주절거리는 주석

• 독자에게 의미가 전달되지 않는다면 소용없다. 주석을 달기로 결정했다면 충분한 시간을 들여 최고의 주석을 달도록 노력한다.

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

• 주석이 코드 내용 그대로 중복된다. 코드보다 읽기가 쉽지도 않고 시간이 더 오래 걸린다.

오해할 여지가 있는 주석

• 코드보다 읽기도 어려운 주석에 담긴 ‘살짝 잘못된 정보’로 인해 코드와 주석이 불일치하게 된다. 다른 프로그래머가 해당 주석만 보고 함수를 사용하게되면 끔찍하다.

의무적으로 다는 주석

• 모든 함수, 변수에 주석을 다는 규칙은 어리석기 그지없다.
  오히려 코드만 헷갈리게 만들며, 잘못된 정보를 제공할 여지만 만든다.

이력을 기록하는 주석

• 모든 모듈 첫머리에 변경 이력을 기록하고 관리하는 관례가 바람직했다. 당시에는 소스 코드 관리 시스템이 없었으니까. 소스 코드 관리 시스템을 사용할테니 이제는 완전히 제거하는 편이 좋다.
  • ex)
    2002-05-13 : checkParam() 추가
    2002-05-15 : checkParam() 정정

있으나 마나 한 주석

• 너무 당연한 사실을 언급하며 새로운 정보를 제공하지 못한다.
  • ex) // 기본 생성자
    public Car() {}
• 지나친 주석은 주석을 무시하는 습관에 빠뜨린다.

무서운 잡음

• 주석을 주의 깊게 작성하지 않음으로 인해 오히려 혼란을 준다.

// name
private String name;
// code
private String code;
// code (copy&paste)
private String version;

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

• 주석을 달지 말고 변수/함수의 적절한 이름을 지어주자.

위치를 표시하는 주석

• 배너 아래 특정 기능을 모아놓으면 유용한 경우도 있긴 하다. 다만 배너는 주의를 환기하므로 남용해서는 안된다.
  • ex) // Actions ///////////////////////////

닫는 괄호에 다는 주석

• 중첩이 심하여 닫는 괄호에 주석을 달곤 한다. 그럴 때는 작게 캡슐화된 함수로 분리한다.

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

• 소스 코드 관리 시스템에 저장하는 편이 좋다. 저자 이름으로 코드를 오염시킬 필요가 없다.

주석으로 처리한 코드

• 주석으로 처리된 코드는 다른 사람들이 지우기를 주저한다. 이유가 있어 남겨 놓았으리라고, 중요하니까 지우면 안 된다고 생각한다. 소스 코드 관리 시스템이 우리를 대신해 코드를 기억해준다. 그냥 코드를 삭제하라. 잃어버릴 염려는 없다.

HTML 주석

• 소스 코드에서 HTML 주석은 혐오 그 자체다. IDE에서 조차 읽기가 어렵다.

전역 정보

• 주석을 달아야 한다면 근처에 있는 코드만 기술하라. 다른 코드에 영향을 받는 주석을 작성해서는 안된다. 코드가 변해도 주석이 변하리라는 보장은 전혀 없다.

너무 많은 정보

• 주석에다 흥미로운 역사나 관련 없는 정보를 장황하게 늘어놓을 필요 없다.

모호한 관계

• 주석과 주석이 설명하는 코드는 둘 사이 관계가 명백해야 한다. 주석을 다는 목적은 코드만으로 설명이 부족해서다.

함수 헤더

• 짧고 한 가지만 수행하며 이름을 잘 붙인 함수가 주석으로 헤더를 추가한 함수보다 훨씬 좋다.

비공개 코드에서 Javadocs

• 공개하지 않을 코드라면 Javadocs는 쓸모가 없다. 코드만 보기 싫고 산만해질 뿐이다.

Reference

• CleanCode 애자일 소프트웨어 장인 정신