Hacker News 의견

• 코드에 주석을 달 때, "왜"와 "왜 안 되는지"를 주로 설명함. 복잡한 코드일 경우 "무엇"을 간단히 설명하는 것도 유용함

  • 의무적인 주석은 비효율적이며, 모든 함수에 주석을 다는 것은 시간 낭비임
  • 도구가 자동으로 추가하는 주석도 비효율적임

• 주니어 엔지니어는 코드가 무엇을 하는지 설명하는 주석을 작성하고, 중급 엔지니어는 왜 그렇게 작성했는지 설명하며, 시니어 엔지니어는 다른 방식으로 작성하지 않은 이유를 설명함

• 유지보수자를 위한 주석 템플릿을 사용함

  • "이 코드는 <이유> 때문에 이렇게 작성됨. 수정하려고 시도한 후 실수임을 깨달으면, 다음 사람을 위해 카운터를 증가시켜 주세요: total_hours_wasted_here = n"

• 코드에서 놀라운 부분에 주석을 다는 것이 중요함

  • 코드가 나중에 이해될지 확신이 서지 않을 때 "왜 안 되는지"를 설명하는 주석을 작성함

• 주석의 중요성을 강조하며, 특히 자신의 코드를 5, 10, 15년 후에도 유지보수해야 할 때 유용함

  • 기존 코드와 일관성을 유지하는 것이 중요함

• "순진한 해결책이 아닌 것"에 주석을 다는 것이 좋음

  • 비효율적인 코드가 나중에 수정될 때 문제를 일으킬 수 있음

• 긴 함수 이름이나 테스트 케이스 이름에 주석을 포함시키는 것이 좋음

  • 메서드 이름이 명확하지 않을 때 주석이 도움이 됨
  • 메서드 설명에 "그리고"가 포함되면 메서드가 너무 많은 일을 하고 있다는 신호임

• 디버그 로깅을 통해 입력이 원래 설계 제약보다 클 때 경고를 추가하는 것도 유용함

• 주석과 문서 주석을 많이 사용하는 것을 선호함

  • 애플리케이션의 단계별로 주석을 작성하고, 코드를 작성하면서 주석을 세분화함
  • 모든 함수와 변수에 주석을 다는 것을 선호함

• 코드 리뷰에서 예상되는 비판을 미리 방지하기 위해 "X를 하지 않은 이유는 Y 때문"이라는 주석을 작성함