지식발전소!! [강컴]

Home >

C++ 코딩의 정석 : 101가지 규칙, 가이드라인, 좋은 습관들

지은이 HERB SUTTER | 출판사 정보문화사 | 발행일 2005년 04월 11일

POD(Printed On Demand)

디지털 데이터 상태로 책(출판콘텐츠)을 저장 해 두었다가 소비자가 구매를 원하는 즉시 인쇄, 제본, 배송을 해주는 다 품종 소량 생산 출판시스템을 말합니다.

	판매가	16,000원 → 11,680원 27%
	마일리지	1% 120원

	발행일	2005-04-11
	ISBN	8956742553 \| 9788956742557
	기타정보	번역서 \| 341쪽

예상출고일

배송비

2,000원 (20,000원이상 무료배송)

프로그래밍언어

종합지수 16p 115 위

	이 책의 원서
		C++ Coding Standards: Rules, Guidelines, and Best Practices Addison-Wesley Professional \| Herb Sutter

「C++ 코딩의 정석: 101가지 규칙, 가이드라인, 좋은 습관들」. 이 책은 C++ 프로그래밍에 있어서 이해하고 지켜나가야 할 내용들을 101가지로 세분화하여 엮은 것이다. 각각의 가이드라인들은 구체적이고 상세하다기보다는 핵심적인 내용 중심으로 정리되어 있다. 각 규칙에 대한 설명과 예, 그리고 예외 상황과 참고 문헌의 순서로 나열하였다.

구성과 관리에 관한 이슈들
0. 작은 것에 연연하지 말라
1. 사소한 경고 메시지라도 무시하지 말라
2. 자동화된 빌드 시스템을 사용하라
3. 버전 컨트롤 시스템을 사용하라
4. 코드 리뷰에 시간을 투자하라

디자인 스타일
5. 하나의 엔티티에는 하나의 역할만을 부여하자
6. 정확성, 간결성, 명확성을 먼저 생각하라
7. 적절한 규모 유지를 위해서는 '언제, 어떻게'를 아는 것이 중요하다
8. 이른 최적화를 피하라
9. 미리 최적화해두어야 할 부분도 있다
10. 전역 데이터와 공유 데이터를 최소화하라
11. 정보를 숨겨라
12. 안전한 공유를 위한 코딩의 시기와 방식을 결정하라
13. 자원은 개체가 가지게끔 하라. RAII와 스마트 포인터를 활용하라

코딩 스타일
14. 런타임 오류보다는 컴파일이나 링크 타임 오류가 낫다
15. const를 사용하라
16. 매크로 사용을 자제하라
17. 마법의 숫자는 쓰지 말라
18. 가능하면 로컬 변수를 선언하여 사용하라
19. 변수는 항상 초기화하여 사용하라
20. 너무 긴 함수와 많은 중첩 구조는 피하라
21. 컴파일 단위 사이의 초기화 의존성을 없애라
22. 정의의 의존성과 순환 의존성을 최소화하라
23. 헤더 파일은 충분히 완성된 형태로 만들어라
24. 내부 #include 가드를 사용하라. 외부 #include 가드를 써서는 안 된다

함수와 연산자
25. 값, (스마트) 포인터, 참조 중 적절한 방식으로 인자를 얻어라
26. 오버로딩된 연산자의 본래 의미를 유지하라
27. 표준적인 형식의 산술 및 할당 연산자를 사용하라
28. ++와 --의 표준적인 형식과 접두 형식을 사용하라
29. 간접적인 타입 변환을 피하기 위해 오버로딩을 활용하라
30. &&, || 그리고 콤마의 오버로딩은 피하라
31. 함수 인자의 처리 순서에 좌우되는 코드는 좋지 않다

클래스 디자인과 상속성
32. 만들고 있는 클래스가 무엇인지 확실히 하라
33. 최소화된 클래스를 사용하라
34. 상속성은 주의해서 사용하라
35. 기반 클래스로 디자인되지 않은 클래스로부터의 상속을 피하라
36. 추상 인터페이스를 활용하라
37. 상속의 정확한 의미를 이해하자. 재사용을 위해 상속하는 것은 아니지만, 재사용은 필요하다
38. 안전한 오버라이딩을 연습하라
39. 가상 함수는 비공용으로, 공용 함수는 비가상으로 설정하라
40. 간접 변환을 피하라
41. 특징 없는 값의 집합(C 스타일의 struct)을 제외하고는 모든 데이터 멤버를 사영으로 유지하라
42. 내부의 것은 너무 노출시키지 말라
43. Pimpl을 적절히 활용하라
44. 비멤버 함수를 활용하라
45. new와 delete는 항상 함께 제공하라
46. 특정한 클래스에 맞는 new를 제공한다면 모든 표준 형식을 제공해야 한다

생성과 파괴 그리고 복사
47. 멤버 변수의 정의와 선언은 같은 순서로 하라
48. 컨스트럭터 내에서 할당 대신 초기화를 사용하라
49. 컨스트럭터와 디스트럭터에서는 가상 함수의 호출을 피하라
50. 기반 클래스 디스트럭터는 공용과 가상 또는 보호와 비가상으로 만들어라
51. 디스트럭터, 재할당 그리고 swap은 절대 실패하지 않는다
52. 일관된 방식으로 복사하고 제거하라
53. 복사의 허용 여부는 명확하게 지정하라
54. 개체의 조각화를 피하라. 기반 클래스 내에서의 복사보다는 Clone을 활용하라
55. 정규형의 할당 방식을 사용하라
56. 필요하다면 실패가 없는 swap을 활용하라

네임스페이스와 모듈
57. 타입과 그의 비멤버 함수는 같은 네임스페이스 내에 넣어라
58. 특별히 함께 작동하게끔 의도된 경우가 아니라면 타입과 함수는 분리된 네임스페이스에 넣어라
59. 헤더 파일 내에 또는 #include 앞에 네임스페이스 using을 써서는 안 된다
60. 서로 다른 모듈에서의 메모리 할당과 해지는 피하라
61. 헤더 파일 내에는 서로 연결된 엔티티를 정의해서는 안 된다
62. 예외가 모듈의 경계를 넘어 전달되는 것을 막아라
63. 모듈의 인터페이스 내에는 충분한 이식성을 갖춘 타입을 사용하라

템플릿과 일반성
64. 정적, 동적인 다형성을 적절히 혼합하라
65. 계획적이고 직접적으로 커스텀화하라
66. 함수 템플릿은 특화해서는 안 된다
67. 계획적이지 않고 일반적이지 않은 코드는 작성하지 말라

오류와 예외의 처리
68. 내부적인 가정과 규칙을 확실하게 명시하라
69. 합리적인 오류 처리 방식을 수립하고, 엄격히 그 방식을 따르라
70. 어디까지가 오류인지 명확히 해두자
71. 오류로부터 안전한 코드를 디자인하고 작성하라
72. 오류 보고에는 예외를 활용하라
73. 예외를 발생시킬 때에는 값으로 하고, 잡아낼 때에는 참조로 하라
74. 목적에 맞게 오류를 보고하고, 제어하고, 변환하라
75. 예외 명세표는 만들 필요가 없다

STL : 컨테이너
76. 표준적으로 vector를 사용하고, 그렇지 않다면 적절한 컨테이너를 선택하라
77. 배열 대신 vector와 string을 사용하라
78. C++ API가 아닌 다른 것들과의 데이터 교환을 위해서는 vector(그리고 string::c_str)를 사용하라
79. 컨테이너에는 값과 스마트 포인터만을 저장하라
80. 요소의 추가에는 push_back을 활용하라
81. 추가 작업에 있어 범위를 지정한 방식을 활용하라
82. 용량의 축소와 요소의 제거에 있어 적절한 방법을 사용하라

STL : 알고리즘
83. 검증된 STL 임플리먼테이션을 사용하라
84. 직접 작성한 루프보다는 알고리즘을 활용하라
85. 적절한 STL 검색 알고리즘을 사용하라
86. 적절한 STL 정렬 알고리즘을 사용하라
87. 술어를 순수한 함수로 만들어라
88. 알고리즘과 비교 인자에는 함수보다 함수 개체를 사용하라
89. 올바른 함수 개체를 만들자

타입 안전
90. 타입의 변환을 피하고, 다형성을 활용하라
91. 표현 방식이 아닌 타입에 의존하라
92. reinterpret_cast 사용을 자제하라
93. 포인터에 대한 static_cast 사용은 피하라
94. const는 캐스팅하지 말자
95. C 스타일의 캐스팅은 사용하지 말라
96. POD가 아닌 데이터를 memcpy 또는 memcmp하지 말라
97. union 사용을 주의하라
98. 가변 인자의 사용을 피하라
99. 올바르지 않은 개체와 안전하지 않은 함수는 사용하지 말라
100. 배열을 다형적으로 다루어서는 안 된다

참고 목록

핵심 요약

찾아보기

Herb Sutter는 세 권의 시리즈 서적인 [Exceptional C++ Style], [Exceptional C++ : C++ 프로그래머를 자극하는 47개의 재미있는 퍼즐 문제], [More Exceptional C++]의 저자이며, ISO C++ 표준 위원회의 일원이자 C/C++ 유저 저널의 컬럼리스트이기도 하다. 또한 마이크로소프트의 소프트웨어 설계사로서 C++ 언어를 .NET 버전으로 확장하는 프로젝트에 참가하고 있다.

Andrei Alexandrescu는 [제네릭 프로그래밍과 디자인 패턴을 적용한 Modern C++ Design ]의 저자이자, C/C++ 유저 저널의 컬럼리스트이다.

[역자의 말]

프로그래머로 일하는 역자의 친구와 이런저런 얘기를 나누다가 자신의 개발팀에서 하는 일들과 팀원들에 대한 대화를 나눈 적이 있다. 프로젝트 마스터가 정해놓은 규칙 때문에 골치가 아프다는 내용이 주를 이루었는데, 많은 팀원들이 그 규칙이 효율적이지 못하다고 지적했지만 받아들여지지 않았고, 심지어는 팀을 떠난 사람도 있다고 했다. 변수의 이름은 항상 한글로 할 것, 특별한 경우가 아니면 모든 변수의 범위를 전역(global)으로 설정할 것 등이 대표적인 규칙이었고, 그 얘기를 들으면서 역자가 만약 그 팀의 일원이었더라도 꽤나 골치가 아프지 않았을까 하는 생각이 들었다.

프로그래밍을 함에 있어서 어떠한 기준을 바탕으로 삼아야 할까? 코딩 환경이 다양하고 프로젝트의 종류 또한 다양하겠지만 기본적인 가이드라인들은 반드시 존재하고, 특별한 이유가 없는 한 그 가이드라인을 따르는 것이 여러모로 이득이 된다. 코딩의 표준 방식은 그만큼 많은 사람들이 많은 시간과 노력을 통해 경험하고 발전시킨 것이며, 효율적이고 안전함이 입증된 것이기 때문이다.

이 책은 C++ 프로그래밍에 있어서 여러분이 이해하고 지켜나가야 할 내용들을 101가지로 세분화하여 엮은 것이다. 각각의 가이드라인들은 구체적이고 상세하다기보다는 핵심적인 내용 중심으로 정리되어 있으며, 각 규칙에 대한 설명과 예, 그리고 예외 상황과 참고 문헌의 순서로 나열되어 있다.

아마도 이 책은 C++ 프로그래밍에 익숙한 전문가일수록 더 유용하게 읽혀질 것이라 생각한다. 당연하게 여겨지지만 그 이유는 정확히 설명하지 못하던 표준적인 코딩 방식, 잘 알지 못했기 때문에 잘못 해왔던 그동안의 방식, 알면서도 그 중요성을 깨닫지 못해 잘 지키지 못했던 여러 표준들에 대한 명확한 해답을 이 책에서 제시하고 있기 때문이다.

문체나 구성의 특성상 이 책은 C++ 프로그래밍의 설명서나 레퍼런스라기보다는 철학서에 가깝다. 단어 선택이나 문장 구성에 있어서도 그러한 특성이 그대로 반영되어 있어, 역자가 그동안 경험한 원서 중 가장 번역이 힘들었던 책이기도 하다. 때문에 최대한 독자들이 쉽게 읽을 수 있게끔 풀어쓰려 노력했고, 이해에 도움이 안 되는 부분들은 생략했으며, 필요에 따라 조금씩 부연설명을 추가하였다.
여러분이 좋은 프로그래머가 되고자 한다면 역자의 친구가 속해있는 팀의 프로젝트 마스터와 같이 프로그램 전체의 질을 떨어뜨리는 그런 엉뚱한 규칙은 만들지도 말고, 따르지도 말자. 그 이유와 방법은 이 책에 담겨있다.