클린코더스 - 백명석님 강의를 보고 작성한 글입니다.
조직이 일정수준의 크기가 되면 문서화를 요구한다. 하지만 별도의 문서를 작성하는 것은 반대!!
처음에는 별도의 문서가 있어도 괜찮을거라고 생각이 들었는데 강의를 듣다보니 생각이 바뀌었다. 코드에 대한 설명을 코드 자체로 설명하는 것이지 별도의 문서로 설명한다는 것은 아니라고 한다. 별도의 문서가 필요하다는 말은 해당 코드가 Coding Standard의 예로 적합하지 않다는 뜻이 된다.
Comments 작성을 강요하면 프로그래머는 필요해서가 아니라 해야하므로 Comment를 작성하게된다.
그리고 이런 Comments는 무의미하고, 무시당하기 십상이다. 너무해ㅠ
Comments를 보는사람이 감사하는 마음이 생겨야 좋은 Comments이다.
모든 Comments는 당신의 코드가 '제대로 표현되고있지않다'라는 실패의 상징이다.
이 말은 좀 충격이었다. 지금까지 사람들에게 내 코드를 이해시키기위해 주석을 열심히 써왔는데... 차라리 이 노력을 코드표현력에 쏟을걸 하는 생각이 들었다.
그렇다면 Comments를 꼭 써야하는 상황에서의 좋은 Comments 그리고 나쁜 Comments는 무엇일까?
Legal Comments
Informative Comments
...
// format matched kk:mm:ss EEE, MMM dd, yyyy
Pattern timePattern = Pattern.compile("\\d*:\\d*:\\d* \\w*. \\w* \\d*, \\d*");
...
Warning of Consequences
// don't run unless you have some time to kill
@Test
public void readReallyBigFile() {...}
TODO Comments
Mumbling
Redundant Explanations
// The Child Containers belong to this container, keyed by name
private Map<String, Child> children = new HashMap<String, Child>();
Mandated Redundancy
/**
*
* @param dateIn input date
* @return formatted string
*/
public static String convertDateFormat(String dateIn) {
...
}
Journal Comments
/**
* 변경이력
* 2018.11.01 : 생성
* 2018.11.05 : convertDateFormat 메소드 구현 ...
*/
Noways Comments
public class DateFormatUtils {
/**
* default constructor
*/
public DateFormatUtils() {
...
}
}
Big Banner Comments
public class DateFormatUtils {
/************************
* instance variables *
************************/
private int day;
private int date;
...
}
Closing Brace Comments
for (int i = 0; i< length; i++) {
if(...) {
} //end of if
} //end of for
Attribution Comments
// add by jm
private class Child {
}
HTML in Comments
Non-Local Information
잘보고가용