프로그래밍 입문자들이 하는 실수 중에 하나가 너무 코맨트가 적거나 또는 너무 많은 코멘트를 다는 거죠.
과도한 코멘트는 마치 책를 읽으면서 중요한 대목에서만 밑줄을 쳐야 하는데
그걸 과도하게 밑줄이 많이 쳐서 나중에 다시 그 책을 보면 밑줄을 거의 치지 않은 거보다 못할 수도 있지요.
즉 다음에 책을 다시 봤을 때 꼭 봤으면 싶은데만 밑줄을 쳐서 강조해야죠.
코멘트 에 대해 말하자면 전체적인 설명 외에는 개별 문장은 코멘트 없이도 코드를 쉽게 이해할 수 있는게 최상이죠.
그런 사상중에 하나가 Literate programing 이라고 프로그램 코드 자체를 문학처럼 읽으면 이해될 수 있도록
마치 다른 사람에게 설명하듯이 작성하는 거죠.
즉 프로그램 소스코드는 컴퓨터 라는 기계에게 일을 시키는 명령문일 뿐 만 아니라
프로그램의 구조나 동작을 쉽게 이해할 수 있도록
작성자의 의도를 다른 프로그래머에게 전달하는 설명서라는 거죠.
즉 알고리즘 교과서에 알고리즘을 코드로 설명하듯이
다른 동급 개발자에게 자기 코드를 설명하듯이 코드가 쓰여져야 한다는 거죠.
나중에 그 프로그램을 유지보수하기위해 그 코드를 이해하고 고쳐야 하는 다른 사람이
그 코드만 보고 이 코드가 무얼 하자는 건지 왜 그랬는지 이해하기 어려울 때 (어려움이 예상될 때)
그 유지보수를 맡은 다른 프로그래머에게 이게 뭘하는 건지 설명을 하는 식으로 코멘트가 쓰여 져야 합니다.
코멘트를 다 읽어야 하는 것도 유지보수자에게는 부담입니다.
무엇보다 그 프로그램을 유지보수하는 사람이 3년 후에 다른 업무를 하다가 불려나온 당신 자신일 수 있습니다.
그래서 미래의 자신을 위해 자신에게 설명하는 코멘트를 꼭 달아야 하죠.
대체로 3년 후에 자기가 다시 그 코드를 봤을 때 그 코드를 쉽게 이해할 자신이 있으면
코멘트를 달 필요가 없고 반대로 자세히 보지 않으면 이해가기 어렵거나 헷갈릴만 하다면
코멘트로 설명을 해주어야죠.
특히 유지보수자 입장에서 그 많은 소스 코드 라인 중에 어디를 잘 살펴보고
어떻게 손대야 하는지 쉽게 알 수 있어야죠.
즉 프로그램의 코맨트는 미래의 자신에게 하는 설명이라고 보시면 됩니다.
