2004-11-24

Code Review Tips

당신의 프로그램이 다운된다면, 혹은 메모리 누수가 심하다면 다음과 같은 룰을 기반으로 코드를 리뷰하라. 이때, 코드 작성자가 아닌 다른 프로그래머를 항상 옆에 대동하면 버그를 찾을 확률은 200% 증가할 것이다. (사실 이건 내부 자료인데 몰래 공개하는 것이다. 헤헤)

상속 관계의 베이스 클래스에 virtual destructor 를 선언했는가?
배열 포인터를 delete[] 로 삭제하는가?
delete:Wh*[]으로 정규식 검색을 하면 편하다.
배열이 아닌 포인터를 delete[] 로 삭제하는가?
memcpy(), memset(), memmove(), strcpy() 메모리 관련 함수들의 BoundCheck가 잘 되어 있는가?
배열을 인덱싱할 때 파라미터의 BoundCheck 가 잘 되어 있는가?
다른 peer 로 부터 넘어온 모든 정수형 파라미터에 대한 BoundCheck가 잘 되어 있는가? (특히 문자열 길이에 유의)
STL string 을 사용한다면, %s 포맷팅할 때 c_str() 을 사용하는가?
Singleton 이나 STL 컨테이너에 대해서 2개 이상의 쓰레드가 동시에 읽기/쓰기 모드로 접근하는 경우 lock 을 걸고 있는가?
사용하지 않는 copy constructor, assignment operator 가 private 로 선언되어 있는가?
포인터 멤버를 가진 객체를 복사할 때 assignment operator 를 재정의했는가?
Warning Level 을 4 로 높인 다음 컴파일해봤는가?
초기화하지 않고 사용하는 변수(또는 클래스 데이터 멤버)가 가장 위험하다.
try ~ catch( ... )은 절대 사용하지 말라. SEH Exception 까지도 캐치해버린다.버그를 숨겨서 더 큰 버그를 만들 뿐이다.
set_se_translator() 를 쓰지 마라. 쓰레드 로컬이라, 매 쓰레드마다 해줘야 한다. SetUnhandledExceptionFilter()는 프로세스 글로벌이다.