> For the complete documentation index, see [llms.txt](https://real-dev.gitbook.io/real-library/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://real-dev.gitbook.io/real-library/clean-code/readme/4..md).

# 4. 주석

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

<br>

* 주석은 잘 쳐줘봐야 필요악이다. 믿어선 안되고 널럴하게 대해선 안 된다.
* 코드로 의도를 표현하지 못해서 주석을 다는 일은 끔찍하다. 또한 주석을 프로그램에서 영향을 미치지 못하기 때문에 관리되지 않고, 코드의 방향성과 멀어질 가능성이 아주 높다.
* 부정확한 주석은 없는 것보다 훨씬 더 나쁘다.
* 주석은 나쁜 코드를 보완하지 못한다.

![Untitled](/files/MKWxczcLpFrvzMJgA4RH)

주석으로 해결하기보단, 기능을 잘 나타내는 함수가 더 낫다.

#### 좋은 주석

* 정말 코드로 나타낼 수 없거나, 남들이 알기 어려운 중요성을 강조하는 주석은 역할에 충실한 주석이 될 수 있다.

![Untitled](/files/n5YYjgSJvjjn27XY46qO)

![Untitled](/files/KW7yZpYgLeSTVNaucN8R)

좋은 주석의 사례

* TODO도 나쁘진 않다. 단, 떡칠될 상태로 방치하지 말고 주기적으로 정리해야 한다.

<br>

#### 나쁜 주석

* 허술한 코드를 지탱하거나, 엉성한 코드를 변명하거나, 미숙한 결정을 합리화하는 주석은 프로그래머가 주절거리는 독백에서 크게 벗어나지 못한다. ~~신랄하여라…~~
* 주석 처리한 코드를 계속 남겨놓는 것도 안티 패턴이다. 버전 관리 프로그램이 잘 해준다. 제발 지워라
* 누가 작성했는지도 버전 관리 프로그램이 잘 해준다…
