코드 자체만으로 의도를 표현하는 게 좋다.
- 주석을 안 좋게 보는 이유: 코드를 고칠 때 함께 고치지 않으면 틀린 설명이 된다.
--> 나쁜 코드에 주석 달아서 그럴싸해보이게 하지 말고 코드를 가독성있게 다시 짜라!
좋은 주석?
- 법적인 주석 (copyright...)
- 정보를 제공하는 주석 (ex. 어떤 인스턴스인지 / 정규 표현식 설명)
--> 함수나 클래스로 분리해 주석을 없애는 게 더 낫다
- 의미를 명료하게 밝히는 주석 (ex. 모호한 인수나 리턴값)
--> 명확한 표현을 써서 만들면 좋지만 라이브러리 코드처럼 변경이 안되는 경우
- 결과를 경고하는 주석
- TODO 주석
- 중요성을 강조하는 주석 (남들이 대수롭지 않게 생각할 것 같은 부분인데 사실 그러면 안되는 포인트인 곳들)
나쁜 주석?
- 주절거리는 주석 (주석을 봐도 이해가 안돼서 코드를 뒤져봐야 하는 경우)
- 같은 이야기를 중복하는 주석 (코드만 봐도 이해가 되는 부분은 굳이 주석을 달 필요가 없다)
- 오해할 여지가 있는 주석
- 의무적으로 다는 주석
- 이력을 기록하는 주석 (요즘은 git을 쓰니까 굳이 쓸 필요가 없다)
- 있으나마나 한 주석 (새로운 정보를 제공하지 못하고 너무 당연한 사실만 언급하는 것)
- 함수나 변수로 표현할 수 있다면 주석을 달지 않아도 된다
- 위치를 표시하는 주석
- 닫는 괄호에 다는 주석 (ex. class A { ... } // 설명)
- 주석 처리 된 코드 (이유가 있어서 안 지운줄 알고 계속 남게 된다)
- HTML 주석
- 전역 정보
- 너무 많은 정보
- 함수 헤더
주석을 무조건 남기는 것이 아니라 적재적소에 써야한다는 걸 깨닫게 되었다. 최대한 설명을 잘 써두는 것만이 능사는 아니었구나! 앞으로는 최대한 변수나 함수, 클래스 등을 가독성있게 구현해서 주석이 크게 필요 없는 정도로 만드는 게 좋겠다.
'books > clean code' 카테고리의 다른 글
6. 객체와 자료구조 (0) | 2023.12.13 |
---|---|
5. 형식 맞추기 (0) | 2023.12.11 |
3. 함수 (1) | 2023.12.07 |
2. 의미있는 이름 (0) | 2023.12.05 |
1. 깨끗한 코드 (0) | 2023.12.04 |