[클린코드] 8일차 - 나쁜 코드에 주석을 달지 마라. 새로 짜라. 하지만 좋은 주석은 분명히 있다.

[클린코드] 8일차 - 나쁜 코드에 주석을 달지 마라. 새로 짜라. 하지만 좋은 주석은 분명히 있다.

클린코드 8일차 (p. 67~74(4장) )

4 주석

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

- 주석은 쉰들러 리스트가 아니다. ‘순수하게 선하지‘ 못하다. 
- 주석은 항상도 아니고 고의도 아니지만 너무 자주 거짓말을 한다. 
- 왜냐? 현실적으로 주석을 유지보수하기 쉽지 않기 때문이다.

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

- 깔끔하고 주석이 거의 없는 코드가, 복잡하며 주석이 많이 달린 코드보다 훨씬 좋다.

2. 코드로 의도를 표현하라!

- 확실히 코드만으로 의도를 설명하기 어려운 경우가 존재하지만, 많은 개발자들이 코드는 훌륭한 수단이 아니라는 의미로 해석한다.

3. 좋은 주석

1) 법적인 주석

- 회사가 정립한 구현 표준에 맞춰 법적인 이유로 특정 주석을 넣으라고 명시하는 경우

- ex) 소스 파일 첫머리에 주석으로 들어가는 저작권 정보와 소유권 정보

2) 정보를 제공하는 주석

- 가능하다면, 함수 이름에 정보를 담는 편이 좋다.

3) 의도를 설명하는 주석

- 때때로 어떤 주석은 결정에 깔린 의도까지 설명하는 경우도 있다.

4) 의도를 명료하게 밝히는 주석

- 인수나 반환값 자체를 명확하게 만들면 더 좋겠지만, 인수나 반환값이 표준 라이브러리나 변경하지 못하는 코드에 속한다면 !

5) 결과를 경고하는 주석

- 프로그래머에게 결과를 경고할 목적

- ex) // 여유 시간이 충분하지 않다면 실행하지 마십시오 .. 와 같은 특정 테스트 케이스를 꺼야하는 이유를 설명하는 주석

- 물론 요즘에는 @Ignore 속성을 이용해 테스트 케이스를 꺼버린다. (@Ignore("실행이 너무 오래 걸린다"))

6) TODO 주석

- 앞으로 할일을 //TODO 주석으로.

- 요즘 IDE는 TODO 주석을 전부 찾아 보여주는 기능을 제공한다.. 나도 최근 //TODO 주석을 작성한 적이 잇다..!

- 주기적으로 TODO 주석을 점검할 필요는 있다.

7) 중요성을 강조하는 주석

- 자칫 대수롭지 않다고 여겨질 무언가를 위한 주석.