{
즉, 자신 또는 우리가 만들어 놓은 프로그램이 올바르게 작동하기 위해서 내부적인 가정과 규칙을 확실하게 명시해 둘 필요가 있다는 이야기이다.

여기서 말하는 규칙과 가정은 무엇을 말하는가?
 오류의 보고와 오류의 표현, 오류의 범위을 뜻한다.

이것을 왜 확실하게 명시해야 하는가?
나 혼자 작업을 한다면, 일관성 있게 유지해야 함은 나 자신에게 무척 도움이 된다.(나중에 봐도 알 수 있으니까) 마찬가지로 팀에서도 명시된 룰을 적용하면, 모두가 좋다.

대표적으로 assert를 사용하는 사람과 사용하지 않는 사람이 같이 작업을 했다고 했을 때, 릴리즈 모드와 디버깅 모드에서 다른 결과를 볼 수 있는 것을 예로 들 수 있다.

그러므로 확실하게 명시하는 편이 좋다.

부수적인 이야기
 assert 이야기가 나와으니 책에 나온 몇자를 옮긴다면 assert 사용시 assert(!"정보성 메세지") 나 assert( id_ != 0 && "메세지" ) 방식이 좋지 아니한가? 라고 한다.
}

저작자 표시
신고

'책 정리 > C++ Coding Standards : C++ 코딩의 정석' 카테고리의 다른 글

항목 73 : 예외를 발생시킬 때에는 값으로 하고, 잡아낼 때에는 참조로 하라. ( Throw by value, catch by reference. )  (0) 2009.05.02
항목 72 : 오류 보고에는 예외를 활용하라. ( Prefer to use exceptions to report errors. )  (0) 2009.05.02
항목 71 : 오류로부터 안전한 코드를 디자인하고 작성하라. ( Design and write error-safe code. )  (0) 2009.04.29
항목 70 : 어디까지가 오류인지 명확히 해두자. ( Distinguish between errors and non-errors. )  (0) 2009.04.28
항목 69 : 합리적인 오류 처리 방식을 수립하고, 엄격히 그 방식을 따르라. ( Establish a rational error handling policy, and follow it strictly. )  (0) 2009.04.17
항목 68 : 내부적인 가정과 규칙을 확실하게 명시하라. ( Assert liberally to document internal assumptions and invariants. )  (0) 2009.04.17
항목 100 : 배열을 다형적으로 다루어서는 안된다. ( Don’t treat arrays polymorphically. )  (0) 2009.04.17
항목 99 : 올바르지 않은 개체와 안전하지 않은 함수는 사용하지 말라. ( Don’t use invalid objects. Don’t use unsafe functions. )  (0) 2009.04.17
항목 98 : 가변 인자의 사용을 피하라. ( Don’t use varargs (ellipsis). )  (0) 2009.04.17
항목 97 : union 사용을 주의하라. ( Don’t use unions to reinterpret representation. )  (0) 2009.04.17
항목 96 : POD가 아닌 데이터를 memcpy 또는 memcmp하지 말라. ( Don’t memcpy or memcmp non-PODs. )  (0) 2009.04.17
posted by 농사를 짓는 게임 프로그래머 최익필

댓글을 달아 주세요