책 정리/C++ Coding Standards : C++ 코딩의 정석 검색 결과

해당 글 102건
항목 70 : 어디까지가 오류인지 명확히 해두자. ( Distinguish between errors and non-errors. )

{ 개요 에러란 무엇이고, 어디서 발생하는지 이해함으로써, 디버깅 능력 향상을 위해 정리하였습니다. 본문 에러란 무엇인가? 작업이 의도하지 않은 방향으로 가는 것, 이것을 에러라 한다. 이러한 작업의 최소한 단위는 함수인데. 함수가 의도하지 않는 방향으로 간다면, 에러가 발생했다고 봐야 한다. 어디까지 의도하지 않는 방향으로 가야 에러인가? 함수가 자신이 맡은 책임을 다하지 못하고, 다름 함수에게까지 도달한다면, 에러라고 봐야한다. 그렇다면 함수에 어떤 에러가 있을까? 1. 필요한 전제조건이 만족하지 못하고 함수를 호출하는 오류 2. 함수의 결과값이 정상적이지 않는 오류 3. 불변 의무를 가진 변수를 건들거나 복구하지 않는 오류 이러한 오류들이 존재한다. 말로만 설명하지 말고 코드을 보여 줄수 있는가? ..
책 정리/C++ Coding Standards : C++ 코딩의 정석 2009. 4. 28. 20:08
항목 69 : 합리적인 오류 처리 방식을 수립하고, 엄격히 그 방식을 따르라. ( Establish a rational error handling policy, and follow it strictly. )

{ 이 항목은 몸에 와 닿지 않는다. 아무래도 이런 개발 프로세스를 사용해 본적이 한번도 없기 때문이다. 회사에서 로그를 남기는 것으로 처리 하는게 아마도 이런 개발 프로세스 인것 같다. 이것이 왜 중요한가? 보통은 안써도 크게 무리 없지만 프로젝트의 규모가 커지거나, 프로젝트에 붙는 사람들의 숫자가 많아 질 수록 프로젝트의 관리도 더불어 힘들어 진다. 그러면서 디버깅은 점점 힘들어 진다. 만약 오류의 처리 방식, 보고 방식, 표현 방식이 정해져 있다면 좀 더 편할 것이다. 책에서는 모라고 하는가? 개발 초기에 먼저 정하고 개발하라고 한다. 어떻게 정하는가? 오류를 우선 식별하는 기준을 정한다. 예를 들어 babo_num > 30 이면 오류이다. 라고 정한다. 그리고 오류의 수준을 정한다. babo_nu..
책 정리/C++ Coding Standards : C++ 코딩의 정석 2009. 4. 17. 00:11
항목 68 : 내부적인 가정과 규칙을 확실하게 명시하라. ( Assert liberally to document internal assumptions and invariants. )

{ 즉, 자신 또는 우리가 만들어 놓은 프로그램이 올바르게 작동하기 위해서 내부적인 가정과 규칙을 확실하게 명시해 둘 필요가 있다는 이야기이다. 여기서 말하는 규칙과 가정은 무엇을 말하는가? 오류의 보고와 오류의 표현, 오류의 범위을 뜻한다. 이것을 왜 확실하게 명시해야 하는가? 나 혼자 작업을 한다면, 일관성 있게 유지해야 함은 나 자신에게 무척 도움이 된다.(나중에 봐도 알 수 있으니까) 마찬가지로 팀에서도 명시된 룰을 적용하면, 모두가 좋다. 대표적으로 assert를 사용하는 사람과 사용하지 않는 사람이 같이 작업을 했다고 했을 때, 릴리즈 모드와 디버깅 모드에서 다른 결과를 볼 수 있는 것을 예로 들 수 있다. 그러므로 확실하게 명시하는 편이 좋다. 부수적인 이야기 assert 이야기가 나와으니 ..
책 정리/C++ Coding Standards : C++ 코딩의 정석 2009. 4. 17. 00:09
항목 99 : 올바르지 않은 개체와 안전하지 않은 함수는 사용하지 말라. ( Don’t use invalid objects. Don’t use unsafe functions. )

{ 올바르지 않은 개체는 무엇을 뜻하는가? 제거된 객체, 소멸자가 이미 호출된 객체, 핸들의 대상이 사라진 핸들, 형 변환을 통해서 얻은 데이터 등이 있다. 그렇다면 안전하지 않은 함수는? sprintf, memcpy 등 범위 검사가 전혀 없으면서 메모리 작업을 하는 함수들이 있다. 그러면 어떻게 해야 하는가? 간단하다, boost 라이브러리를 적극 활용하거나, 안쓰면 된다. ㅋㅋ 실제로 이 이야기는 KGC2008 컨퍼런스에 갔다가, 마소에서 나온 어떤 개발자를 통해서 들었다. 관련링크 http://www.ikpil.com/710 }
책 정리/C++ Coding Standards : C++ 코딩의 정석 2009. 4. 17. 00:06
항목 98 : 가변 인자의 사용을 피하라. ( Don’t use varargs (ellipsis). )

{ C++ 에서도 가변 인자가 필요한 경우가 있긴 있다. 하지만 C++ 높은 수준의 구조체나 boost 라이브러리 등을 이용하면 굳이 사용하지 않아도 된다. 그렇다면 왜 사용하지 말아야 하는가? 그 이유는 타입 안전성에 약하다. 일단 가변 인자는 타입 안전성 검사를 모두 중단하는 것이다. 그리고 프로그래머가 그 가변 인자를 관리해 주어야 한다. 역시 귀찮은 작업이다. 그리고 클래스 타입의 개체에 대한 결과는 예상하기 힘들다. .. 가변인자를 클래스의 개체를 넣는다면 .. 정말 그 결과를 예상하기 힘들다. 마지막으로 인자의 갯수를 아는 방법이 없다. 하지만 sprintf 등의 함수류에서 무척 간편하게 사용하기도 하고, 로그를 남길 때라든지 무척 편하다는 장점이 있다. 자, 선택은 자신의 몫! 아 그리고 b..
책 정리/C++ Coding Standards : C++ 코딩의 정석 2009. 4. 17. 00:04