본문 바로가기

책 정리/C++ Coding Standards : C++ 코딩의 정석

(102)
C++ Coding Standard : 코딩의 정석 목차 관련 링크해야 하는데, 귀찮.. 구성과 관리에 관한 이슈들 0. 작은 것에 연연하지 말라 1. 사소한 경고 메시지라도 무시하지 말라 2. 자동화된 빌드 시스템을 사용하라 3. 버전 컨트롤 시스템을 사용하라 4. 코드 리뷰에 시간을 투자하라 디자인 스타일 5. 하나의 엔티티에는 하나의 역할만을 부여하자 6. 정확성, 간결성, 명확성을 먼저 생각하라 7. 적절한 규모 유지를 위해서는 '언제, 어떻게'를 아는 것이 중요하다 8. 이른 최적화를 피하라 9. 미리 최적화해두어야 할 부분도 있다 10. 전역 데이터와 공유 데이터를 최소화하라 11. 정보를 숨겨라 12. 안전한 공유를 위한 코딩의 시기와 방식을 결정하라 13. 자원은 개체가 가지게끔 하라. RAII와 스마트 포인터를 활용하라 코딩 스타일 14. 런타..
항목 75 : 예외 명세표는 만들 필요가 없다. ( Avoid exception specifications. ) 관련 링크로 대신 한다. http://ikpil.com/807
항목 74 : 목적에 맞게 오류를 보고하고, 제어하고, 변환하라. ( eport, handle, and translate errors appropriately. ) { 개요 이 포스팅은 오류를 어떻게 할 것인지 결정을 내릴 수 있는 방법을 정리하는 데에 그 목적을 두고 있다. 본문 제일 먼저 무엇을 해야 하는가? 오류를 발생시켜야 한다. 항목 70 항목에서 에러란 무엇인지에 대해서 정리하였다. 그 에러들 중에 만약 처리 할 수 없어, 프로그램을 더 이상 진행 할 수 없는 것이라면, 예외를 던저야 한다. 즉, 오류를 예외로 보고 한다. 오류를 예외로 보고 받은 다음 무엇을 해야 하는가? 해당 오류를 분석을 하여, 예외를 다시 던지거나 하거나, 더 변화 시켜서 던지 거나, 처리해야 한다. 변화 시켜 던지는게 무엇을 말하는가? 더 자세한 예외를 만든다거나, 처리 방법을 바꾸기 위해서 다른 예외로 바꾸는 것을 말한다. 결론 예외는 목적에 맞게 변경 하면 더 좋다. }
항목 73 : 예외를 발생시킬 때에는 값으로 하고, 잡아낼 때에는 참조로 하라. ( Throw by value, catch by reference. ) { 개요 이번 포스팅은 예외를 발생시키는 좋은 예와 잡아낼 때 좋은 예를 정리하는 것에 그 목적을 두고 있다. 본문 예외는 어떻게 발생 시킬 수 있는가? 예외는 try 구문 내에서 throw a; 형태로 발생 시킬 수 있다. 이 때 a 는 어떠한 타입도 가능하다. 즉, 포인터,기본형, 객체형이 가능하다는 뜻이다. 이렇게 발생된 예외는 어떻게 잡을 수 있는가? catch 구문을 통해서 잡을 수 있다. 다음과 같이 catch( int a ) 형태 이다. 위의 a가 int 형이라면 잡을 수 있다. 만약 int 형이 아니라면, 잡을 수 없고 try catch 구문 밖으로 예외는 자동으로 나가게 된다. 예) #include int main( void ) { try { throw "abcdefg\n"; std::c..
항목 72 : 오류 보고에는 예외를 활용하라. ( Prefer to use exceptions to report errors. ) { 개요 이번 포스팅은 예러를 보고 할 때, 예외:Exception와 에러코드:Error Code 중 예외가 어떻게 더 좋은지에 대해서 정리한 것이다. 본문 에러를 보고 한다는게 무슨 의미인가? 에러를 보고 한다는 것은 어떤 에러가 났는지 프로그래머에게 알리는 의미를 갖는다. 에러를 보고하는데 어떤 방법이 있는가? 대표적으로 에러코드(리턴코드)를 이용하여 함수의 리턴값으로 보고하는 형태와 예외(Exception)를 던지는 형태가 있다. 대표적인 이 방법중 무엇이 더 좋은가? 예외를 던지는 형태가 더 좋다. 왜 더 좋은가? 1. 예외는 무시될 수 없다. 리턴코드는 리턴에 대해서 처리 하지 않으면, 그냥 무시하고 넘어간다. 결국 이 것을 처리하기 위해선 항상 리턴코드를 제크해야 하는 번거러움이 있다. 하지만..
항목 71 : 오류로부터 안전한 코드를 디자인하고 작성하라. ( Design and write error-safe code. ) 항목 71 : 오류로부터 안전한 코드를 디자인하고 작성하라 { 라고 .. 책에는 적혀 있다. 번역하다가 Exception 이 오류라고 된거 같다. 본 내용은 예외로부터 안전한 코드를 디자인하고 작성하는 것을 이야기 하는 것이다. 개요 이 포스팅은 발생된 예외:Exception으로 부터 프로그램을 보호해야 하는 이유와 어떤 보호방법들이 있는지, 어떻게 보호해야 하는지에 대해서 정리해 둔 것이다. 본문 발생된 예외로 부터 왜 프로그램을 보호해야 하는가? 보호를 할지 말지는 프로그래머가 정하는 일이다. 만약 "나는 보호하지 않겠어" 라고 한다면, 이 포스팅을 읽지 않아도 된다. 예외가 발생 했을 경우, 그 예외는 자신의 지역에서 처리 할 수 있는 곳이 있는지 살펴보고, 있다면 그곳에 머물러 처리가 될 테니지만..
항목 70 : 어디까지가 오류인지 명확히 해두자. ( Distinguish between errors and non-errors. ) { 개요 에러란 무엇이고, 어디서 발생하는지 이해함으로써, 디버깅 능력 향상을 위해 정리하였습니다. 본문 에러란 무엇인가? 작업이 의도하지 않은 방향으로 가는 것, 이것을 에러라 한다. 이러한 작업의 최소한 단위는 함수인데. 함수가 의도하지 않는 방향으로 간다면, 에러가 발생했다고 봐야 한다. 어디까지 의도하지 않는 방향으로 가야 에러인가? 함수가 자신이 맡은 책임을 다하지 못하고, 다름 함수에게까지 도달한다면, 에러라고 봐야한다. 그렇다면 함수에 어떤 에러가 있을까? 1. 필요한 전제조건이 만족하지 못하고 함수를 호출하는 오류 2. 함수의 결과값이 정상적이지 않는 오류 3. 불변 의무를 가진 변수를 건들거나 복구하지 않는 오류 이러한 오류들이 존재한다. 말로만 설명하지 말고 코드을 보여 줄수 있는가? ..
항목 69 : 합리적인 오류 처리 방식을 수립하고, 엄격히 그 방식을 따르라. ( Establish a rational error handling policy, and follow it strictly. ) { 이 항목은 몸에 와 닿지 않는다. 아무래도 이런 개발 프로세스를 사용해 본적이 한번도 없기 때문이다. 회사에서 로그를 남기는 것으로 처리 하는게 아마도 이런 개발 프로세스 인것 같다. 이것이 왜 중요한가? 보통은 안써도 크게 무리 없지만 프로젝트의 규모가 커지거나, 프로젝트에 붙는 사람들의 숫자가 많아 질 수록 프로젝트의 관리도 더불어 힘들어 진다. 그러면서 디버깅은 점점 힘들어 진다. 만약 오류의 처리 방식, 보고 방식, 표현 방식이 정해져 있다면 좀 더 편할 것이다. 책에서는 모라고 하는가? 개발 초기에 먼저 정하고 개발하라고 한다. 어떻게 정하는가? 오류를 우선 식별하는 기준을 정한다. 예를 들어 babo_num > 30 이면 오류이다. 라고 정한다. 그리고 오류의 수준을 정한다. babo_nu..