Skip to main content

진소희

1. 📌 핵심 개념 정리

✅ 요약하기

  • 나쁜 코드에 주석을 달지 마라. 새로 짜라.
  • 우리는 코드로 의도를 표현하지 못해, 그러니까 실패를 만회하기 위해 주석을 사용한다.
  • 주석은 언제나 실패를 의미한다.
  • 이유란? 프로그래머들이 주석을 유지하고 보수하기란 현실적으로 불가능하니까.
  1. 주석은 나쁜 코드를 보완하지 못한다
    • 코드에 주석을 추가하는 일반적인 이유는 코드 품질이 나쁘기 때문이다.
    • 표현력이 풍부하고 깔끔하고 주석이 거의 없는 코드가 주석이 많은 코드보다 훨씬 좋다.
  1. 코드로 의도를 표현하라!
    • 코드만으로 의도를 설명하기 어려운 경우가 존재한다.
    • 코드로 대다수 의도를 표현할 수 있다. 많은 경우 주석으로 달려는 설명을 함수로 만들어 표현해도 충분하다.
  1. 좋은 주석
    • 법적인 주석: 때로는 회사가 정립한 구현 표준에 맞춰 법적인 이유로 특정 주석을 넣으라고 명시한다.
    • 정보를 제공하는 주석: 때로는 기본적인 정보를 주석으로 제공하면 편리하다.
      • 하지만 가능하다면, 함수 이름에 정보를 담는 편이 더 좋다.
    • 의도를 설명하는 주석: 때대로 주석은 구현을 이해하게 도와주는 선을 넘어 결정에 깔린 의도까지 설명한다.
    • 의미를 명료하게 밝히는 주석
      • 때때로 모호한 인수나 반환값은 그 의미를 읽기 좋게 표현하면 이해하기 쉬워진다.
      • 일반적으로는 인수나 반환값 자체를 명확하게 만들면 더 좋겠지만, 인수나 반환값이 표준 라이브러리나 변경하지 못하는 코드에 속한다면 의미를 명료하게 밝히는 주석이 유용하다.
    • 결과를 경고하는 주석: 다른 프로그래머에게 결과를 경고할 목적으로 주석을 사용한다.
    • TODO 주석: 앞으로 할 일을 //TODO 주석으로 남겨두면 편하다.
      • 프로그래머가 필요하다 여기지만 당장 구현하기 어려운 업무 등등을 기술한다.
      • 하지만 어떤 용도로 사용하든 시스템에 나쁜 코드를 남겨 놓는 핑계가 되어서는 안 된다.
    • 중요성을 강조하는 주석: 자칫 대수롭지 않다고 여겨질 뭔가의 중요성을 강조하기 위해서도 주석을 사용한다.
  1. 나쁜 주석
    • 주절거리는 주석
      • 특별한 이유 없이 의무감으로 혹은 프로세스에서 하라고 하니까 주석을 단다면 시간낭비이다.
      • 이해가 안 되어 다른 모듈까지 뒤져야 하는 주석은 독자와 제대로 소통하지 못하는 주석이다.
    • 같은 이야기를 중복하는 주석: 주석이 같은 코드 내용을 그대로 중복하는 주석이다.
    • 오해할 여지가 있는 주석
      • 의도는 좋았으나 프로그래머가 딱 맞을 정도로 엄밀하게는 주석을 달지 못한 주석.
      • 살짝 잘못된 정보
    • 의무적으로 다는 주석: 모든 함수에 Javadocs를 달거나 모든 변수에 주석을 다는 규칙은 어리석다. 아무 가치도 없다. 오히려 코드만 헷갈리게 만들며, 거짓말할 가능성을 높이며, 잘못된 정보를 제공할 여지만 만든다.
    • 이력을 기록하는 주석
      • 모듈을 편집할 때마다 모듈 첫머리에 다는 주석이다. 그리하여 모듈 첫머리 주석은 지금까지 모듈에 가한 변경을 모두 기록하는 일종의 일지 혹은 로그가 된다.
      • 지금은 혼란만 가중할 뿐. 완전히 제거하는 것이 좋다.
    • 있으나 마나 한 주석: 너무 당연한 사실을 언급하며 새로운 정보를 제공하지 못하는 주석이다.
    • 무서운 잡음: 때로는 Javadocs도 잡음이다.
    • 함수나 변수로 표현할 수 있다면 주석을 달지 마라
    • 위치를 표시하는 주석
      • 소스 파일에서 특정 위치를 표시하려 사용한 주석.
      • 일반적으로 가독성만 낮추므로 제거해야 마땅하다. 반드시 필요할 때만, 아주 드물게만 사용해야 한다.
    • 닫는 괄호에 다는 주석
      • 닫는 괄호에 다는 특수한 주석.
      • 중첩이 심하고 장황한 함수라면 의미가 있을지도 모르지만, 작고 캡슐화된 함수에선 잡음일 뿐이다.
    • 공로를 돌리거나 저자를 표시하는 주석: 소스코드 관리 시스템은 누가 언제 무엇을 추가했는지 귀신처럼 기억한다. 저자 이름으로 코드를 오염시킬 필요가 없다.
    • 주석으로 처리한 코드
      • 주석으로 처리된 코드는 다른 사람들이 지우기를 주저한다. 이유가 있어서 남겨놨을 것이라고 생각하기 때문이다.
      • 소스코드 관리 시스템이 우리를 대신해 코드를 기억해준다.
    • HTML 주석: HTML 주석은 편집기/IDE에서조차 읽기 어렵다.
    • 전역 정보
      • 주석을 달아야 한다면 근처에 있는 코드만 기술하라.
      • 코드 일부에 주석을 달면서 시스템의 전반적인 정보를 기술하지 마라.
    • 너무 많은 정보: 주석에다 흥미로운 역사나 관련 없는 정보를 장황하게 늘어놓지 마라.
    • 모호한 관계: 주석과 주석이 설명하는 코드는 둘 사이 관계가 명확해야 한다.
    • 함수 헤더: 짧은 함수는 긴 설명이 필요없다. 짧고 한 가지만 수행하며 이름을 잘 붙인 함수가 주석으로 헤더를 추가한 함수보다 훨씬 좋다.
    • 비공개 코드에서 javadocs: 공개 API는 Javadocs가 유용하지만 공개하지 않을 코드라면 Javadocs는 쓸모가 없다. 시스템 내부에 속한 클래스와 함수에 Javadocs를 생성할 필요는 없다.

2. 🤔 이해가 어려운 부분

🔍 질문하기

책을 읽으며 이해하기 어려웠던 개념이나 명확하지 않았던 내용을 정리합니다.

  1. 의도를 설명하는 주석
    • 궁금한 점
      좋은 주석에서의 의도를 설명하는 주석과 나쁜 주석과의 확실한 차이가 무엇인지

3. 📚 참고 사항

📢 논의하기

  1. 논의하고 싶은 주제
    • 주제
      좋은 주석에서의 의도를 설명하는 주석과 나쁜 주석과의 확실한 차이가 무엇인지
    • 설명
      • 코드만 봐서는 이유나 목적을 이해하기 어려울 때 사용
      • 미래의 개발자가 맥락을 이해하는 데 도움
      • 단순한 코드 설명이 아닌 결정의 배경을 설명
Back to top