C/C++ , 좋은 프로그래밍 - 원칙

먼저 "어떤 프로그램이 나쁠까?"를 이야기 하자.

여러 문제를 댈 수 있겠지만, 나는 가장 중요한 것으로 에러 처리를 하지 않은 프로그램을 꼽는다.
프로그램이 개발되는 환경은 최적의 환경이다.
최신 라이브러리, 최신 PC, 검증된 네트워크 환경, 깔끔한 관리 등 최고의 환경에서 프로그램을 개발한다. 그러나 그 프로그램이 실행되는 곳은 최악인 경우가 종종 있다.
개발자의 개발 PC에서 나오지 않는 현상이 실제 유저의 손에서 동작하면 많은 버그를 뱉어낸다. QA를 통해서 일정 부분 걸러지기도 하지만 QA를 통과하는 버그는 반드시 존재한다.

에러 처리가 없다면 이런 버그는 심각한 문제를 유발할 때가 종종 있다. 에러 처리가 없는 그 부분에서 버그가 발생하는 것은 행복한 경우다. 그 버그가 돌고 돌아 엉뚱한 곳에서 문제를 일으킨다면 개발자의 PC에서 버그를 찾을 방법은 사실상 없다고 봐도 된다. 그 사용자의 PC와 똑같은 환경을 세팅하던지, 덤프 파일을 받아서 추적하지 않으면 버그를 찾는 것은 거의 불가능하다.

아무리 친숙한 API라도 API에 리턴 값이 존재하고 잘못 동작하는 경우가 명시되어 있다면 반드시 그 값을 검사해야 한다. 팀으로 작업을 하고 있다면 옆의 작업자를 믿으면 안된다. 그 작업자가 넘기는 파라미터와 결과 값은 반드시 검증하는 부분이 있어야 한다.  심지어 이런 원칙은 자기자신에게도 적용해야 한다. 스스로를 믿지 말고 값을 검증해야 한다.
추가로 반론의 여지가 있겠지만, assert의 사용은 자제하라고 하고 싶다. 대부분의 assert는 디버그 모드에서 동작한다. 디버그로 프로그램을 배포할 것이 아닌 이상, assert는 정말 확실한 부분에 최소로 사용하고, assert를 넣을 부분에 에러 처리 루틴을 스스로 만들어 사용하라.

에러 확인이라는 원칙과 더불어 중요한 것은 전체 프로그램의 에러 처리의 과정이다. 개인이면 개인적인 에러처리 과정이 있어야 하고 팀이면 팀 전체에서 유일하게 사용되는 에러 처리 과정이 있어야 한다. 팀 작업에서 에러 처리 과정에 개인 취향을 두어서는 안된다.
하나의 에러 처리 과정은 동료와 과거의 자신을 신뢰하게 하는 수단이다.

개인적으로, 과거에는 모든 클래스에 get_last_error 라는 함수를 두고, 모든 함수는 결과의 성공/실패를 리턴하게 만들었었다. 그러나 몇년간, 프로그램을 만들때마다 느낀 것은 '귀찮다'였다.  그래서 요즘은 try-catch를 사용한다. 단, 모든 예외는 STL의 std::exception만 사용하고 예외를 발생시킬 때는 반드시 이미 만들어 둔 매크로만 사용한다.
귀찮음 때문에 바꾸었지만 상당히 만족스럽다. 만들어 둔 매크로에는 에러 내용, 에러 번호, 발생 함수, 발생 줄 등의 모든 정보를 기록하기 때문에 한눈에 버그가 발생한 부분을 알 수 있다.
개인이든, 팀이든 에러 처리 과정을 반드시 정해 두길 바란다.

이 원칙을 지키고 있다면 어느 순간 자신이 만든 프로그램에 자신이 붙을 것이다. 에러가 발생해서 경고창이 떴다면 그에 맞는 대처를 설명해주면 된다. 또는 친절하게 에러를 설명했다면 사용자는 버그 내용은 레포트 하지도 않고 스스로 해결해서 사용할 것이다.