TIL (Today I Learned)

2022.02.26

오늘 읽은 범위

4장 주석

책에서 기억하고 싶은 내용을 써보세요.

• 잘 달린 주석은 그 어떤 정보보다 유용하다. 하지만 우리는 코드로 의도를 표현하지 못해, 그러니까 실패를 만회하기 위해 주석을 사용한다. 주석은 언제나 실패를 의미한다.

• 코드는 변화하고 진화한다. 불행하게도 주석이 언제나 코드를 따라가지 않는다. 코드만이 정확한 정보를 제공하는 유일한 출처이다. 가능한 주석을 줄이도록 꾸준히 노력해야한다.

• 좋은 주석.

1. 법적인 주석_ 모든 조항과 조건을 열거하는 대신 표준 라이선스나 외부 문서를 참조해도 되겠다.

2. 정보를 제공하는 주석_기본적인 정보를 주석으로 제공하면 편리하다. 가능하다면 함수 이름에 정보를 담는 편이 더 좋다.

3. 의도를 설명하는 주석_구현을 이햐하게 도와주는 선을 넘어 결정에 깔린 의도까지 설명한다.

4. 의미를 명료하게 밝히는 주석_모호한 인수나 반환값은 그 의미를 읽기 좋게 표현하면 이해하기 쉬워진다.

5. 결과를 경고하는 주석_다른 프로그래머에게 결과를 경고할 목적으로 사용한다.

6. TODO 주석_앞으로 할일을 주석으로 남겨두면 편하다.

7. 중요성을 장조하는 주석_자칫 대수롭지 않다고 여겨질 뭔가의 중요성을 강조하기 위해서 사용한다.

8. 공개 API에서 Javadocs_설명이 잘 된 공개 API는 참으로 유용하고 만족스럽다.

• 나쁜 주석.

1. 주절거리는 주석_ 이해가 안되어 다른 모듈까지 뒤져야 하는 주석은 독자와 제대로 소통하지 못하는 주석이다.

2. 같은 이야기를 중복하는 주석_중복적인 주석은 읽는 시간이 더 오래 걸린다. 코드보다 더 많은 정보를 담을 수 없다.

3. 오해할 여지가 있는 주석_주석에 담기 잘못된 정보로 인해 다른 프로그래머는 굼벵이 기어가듯 돌아가는 이유를 찾느라 골머리를 앓는다.

4. 의무적으로 다는 주석_모든 코드에 의무적으로 다는 주석은 어리석다. 헷갈리고 거짓말할 가능성이 있으며 잘못된 정보를 제공할 여지를 만든다.

5. 이력을 기록하는 주석_예전에는 모든 모듈 첫머리에 변경 이력을 기록하고 관리하는 관례가 있었지만 지금은 혼란만 가중시키니 완전히 제거하는게 좋다.

6. 있으나 마나 한 주석_당연한 사실이나 새로운 정보를 제공하지 못하는 주석은 필요없다.

7. 무서운 잡음_때로는 Javadocs도 잡음이다. 문서를 제공해야 한다는 잘못된 욕심으로 탄생한 잡음이다.

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

9. 위치를 표시하는 주석_특정 위치를 표시하려 주석을 사용한다. 반드시 필요할 때만 사용하라.

10. 닫는 괄호에 다는 주석_작고 캡슐화된 함수에는 잡음이다. 주석을 달지말고 대신에 함수를 줄이려 시도하자.

11. 공로를 돌리거나 저자를 표시하는 주석_이런 정보는 소스 코드 관리 시스템에 저장하는 편이 좋다.

12. 주석으로 처리한 코드_주석으로 처리된 코드는 다른 사람들이 지우기를 주저한다. 그냥 코드를 삭제해라. 우수한 소스 코드 관리 시스템이 있으니까!

13. HTML 주석_도구로 주석을 뽑아 웹 페이지에 올릴 작정이라면 주석에 HTML 태그를 삽입해야 하는 책임은 도구가 져야 한다.

14. 전역 정보_주석을 달아야 한다면 근처에 있는 코드만 기술하라. 일부에 달면서 시스템 전반적인 정보를 기술하지 마라.

15. 너무 많은 정보_흥미로운 역사나 관련 없는 정보를 장황하게 늘어놓지 마라.

16. 모호한 관계_주석과 주석이 설명하는 코드는 둘 사이 관계가 명백해야 한다.

17. 함수 헤더_짧은 함수는 긴 설명이 필요 없다. 짧고 한 가지만 수행하며 이름을 잘 붙인 함수가 주석으로 헤더를 추가한 함수보다 훨씬 더 좋다.

18. 비공개 코드에서 Javadocs_공개하지 않을 코드라면 Javadocs가 필요없다.

오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요

• 좋은 주석과 나쁜 주석의 예제를 보게되었는데, 하지말라는 주석처리는 다 하고 있었다. 주석 처리를 안하게 최대한 코드를 잘 작성해야 겠다.

궁금한 내용이 있거나, 잘 이해되지 않는 내용이 있다면 적어보세요.