Стандарты программирования на С++

Вопросы организации и стратегии 13
0. Не мелочитесь, или Что не следует стандартизировать 14
1. Компилируйте без замечаний при максимальном уровне предупреждений 16
2. Используйте автоматические системы сборки программ 19
3. Используйте систему контроля версий 20
4. Одна голова хорошо, а две — лучше 21

Стиль проектирования 23
5. Один объект — одна задача 24
6. Главное — корректность, простота и ясность 25
7. Кодирование с учетом масштабируемости 27
8. Не оптимизируйте преждевременно 29
9. Не пессимизируйте преждевременно 31
10. Минимизируйте глобальные и совместно используемые данные 32
11. Сокрытие информации 33
12. Кодирование параллельных вычислений 34
13. Ресурсы должны быть во владении объектов 37

Стиль кодирования 39
14. Предпочитайте ошибки компиляции и компоновки ошибкам времени выполнения 40
15. Активно используйте const 42
16. Избегайте макросов 44
17. Избегайте магических чисел 46
18. Объявляйте переменные как можно локальнее 47
19. Всегда инициализируйте переменные 48
20. Избегайте длинных функций и глубокой вложенности 50
21. Избегайте зависимостей инициализаций между единицами компиляции 52
22. Минимизируйте зависимости определений и избегайте циклических зависимостей 53
23. Делайте заголовочные файлы самодостаточными 55
24. Используйте только внутреннюю, но не внешнюю защиту директивы #include 56

Функции и операторы 57
25. Передача параметров по значению, (интеллектуальному) указателю или ссылке 58
26. Сохраняйте естественную семантику перегруженных операторов 59
27. Отдавайте предпочтение каноническим формам арифметических операторов и операторов присваивания 60
28. Предпочитайте канонический вид ++ и --, и вызов префиксных операторов 62
29. Используйте перегрузку, чтобы избежать неявного преобразования типов 64
30. Избегайте перегрузки &&, || и , (запятой) 65
31. Не пишите код, который зависит от порядка вычислений аргументов функции 67

Проектирование классов и наследование 69
32. Ясно представляйте, какой вид класса вы создаете 70
33. Предпочитайте минимальные классы монолитным 72
34. Предпочитайте композицию наследованию 73
35. Избегайте наследования от классов, которые не спроектированы для этой цели 75
36. Предпочитайте предоставление абстрактных интерфейсов 77
37. Открытое наследование означает заменимость. Наследовать надо не для повторного использования, а чтобы быть повторно использованным 79
38. Практикуйте безопасное перекрытие 81
39. Виртуальные функции стоит делать неоткрытыми, а открытые — невиртуальными 83
40. Избегайте возможностей неявного преобразования типов 85
41. Делайте данные-члены закрытыми (кроме случая агрегатов в стиле структур C) 87
42. Не допускайте вмешательства во внутренние дела 89
43. Разумно пользуйтесь идиомой Pimpl 91
44. Предпочитайте функции, которые не являются ни членами, ни друзьями 94
45. new и delete всегда должны разрабатываться вместе 95
46. При наличии пользовательского new следует предоставлять все стандартные типы этого оператора 97

Конструкторы, деструкторы и копирование 99
47. Определяйте и инициализируйте переменные-члены в одном порядке 100
48. В конструкторах предпочитайте инициализацию присваиванию 101
49. Избегайте вызовов виртуальных функций в конструкторах и деструкторах 102
50. Делайте деструкторы базовых классов открытыми и виртуальными либо защищенными и невиртуальными 104
51. Деструкторы, функции освобождения ресурсов и обмена не ошибаются 106
52. Копируйте и ликвидируйте согласованно 108
53. Явно разрешайте или запрещайте копирование 109
54. Избегайте срезки. Подумайте об использовании в базовом классе клонирования вместо копирования 110
55. Предпочитайте канонический вид присваивания 113
56. Обеспечьте бессбойную функцию обмена 114

Пространства имен и модули 117
57. Храните типы и их свободный интерфейс в одном пространстве имен 118
58. Храните типы и функции в разных пространствах имен, если только они не предназначены для совместной работы 120
59. Не используйте using для пространств имен в заголовочных файлах или перед директивой #include 122
60. Избегайте выделения и освобождения памяти в разных модулях 125
61. Не определяйте в заголовочном файле объекты со связыванием 126
62. Не позволяйте исключениям пересекать границы модулей 128
63. Используйте достаточно переносимые типы в интерфейсах модулей 130

Шаблоны и обобщенность 133
64. Разумно сочетайте статический и динамический полиморфизм 134
65. Выполняйте настройку явно и преднамеренно 136
66. Не специализируйте шаблоны функций 140
67. Пишите максимально обобщенный код 142

Обработка ошибок и исключения 143
68. Широко применяйте assert для документирования внутренних допущений и инвариантов 144
69. Определите разумную стратегию обработки ошибок и строго ей следуйте 146
70. Отличайте ошибки от ситуаций, не являющихся ошибками 148
71. Проектируйте и пишите безопасный в отношении ошибок код 151
72. Для уведомления об ошибках следует использовать исключения 154
73. Генерируйте исключения по значению, перехватывайте — по ссылке 158
74. Уведомляйте об ошибках, обрабатывайте и преобразовывайте их там, где следует 159
75. Избегайте спецификаций исключений 160

STL: контейнеры 163
76. По умолчанию используйте vector. В противном случае выбирайте контейнер, соответствующий задаче 164
77. Вместо массивов используйте vector и string 166
78. Используйте vector (и string::c_str) для обмена данными с API на других языках 167
79. Храните в контейнерах только значения или интеллектуальные указатели 168
80. Предпочитайте push_back другим способам расширения последовательности 169
81. Предпочитайте операции с диапазонами операциям с отдельными элементами 170
82. Используйте подходящие идиомы для реального уменьшения емкости контейнера и удаления элементов 171

STL: алгоритмы 173
83. Используйте отладочную реализацию STL 174
84. Предпочитайте вызовы алгоритмов самостоятельно разрабатываемым циклам 176
85. Пользуйтесь правильным алгоритмом поиска 179
86. Пользуйтесь правильным алгоритмом сортировки 180
87. Делайте предикаты чистыми функциями 182
88. В качестве аргументов алгоритмов и компараторов лучше использовать функциональные объекты, а не функции 184
89. Корректно пишите функциональные объекты 186

Безопасность типов 187
90. Избегайте явного выбора типов — используйте полиморфизм 188
91. Работайте с типами, а не с представлениями 190
92. Избегайте reinterpret_cast 192
93. Избегайте применения static_cast к указателям 193
94. Избегайте преобразований, отменяющих const 194
95. Не используйте преобразование типов в стиле C 195
96. Не применяйте memcpy или memcmp к не-POD типам 197
97. Не используйте объединения для преобразований 198
98. Не используйте неизвестные аргументы (троеточия) 199
99. Не используйте недействительные объекты и небезопасные функции 200
100. Не рассматривайте массивы полиморфно 201
Список технической литературы 202
Резюме из резюме 206
Предметный указатель 220

Overview:

This book delivers a valuable set of tried-and-true rules, guidelines, and best practices condensed into 101 concise one- and two-page Items. But this book is something more: It also acts as an index into the world’s C++ literature because each Item includes copious references that, in all, cite nearly 100 different top books and articles—from Brooks’ classic The Mythical Man-Month to Vandevoorde and Josuttis’ cutting-edge C++ Templates to the authors’ own previous books—and distill the scattered advice and guidelines into one authoritative handbook.

Table of Contents:

Organizational and Policy Issues
0. Don’t sweat the small stuff. (Or: Know what not to standardize.) 2
1. Compile cleanly at high warning levels. 4
2. Use an automated build system. 7
3. Use a version control system. 8
4. Invest in code reviews. 9

Design Style
5. Give one entity one cohesive responsibility. 12
6. Correctness, simplicity, and clarity come first. 13
7. Know when and how to code for scalability. 14
8. Don’t optimize prematurely. 16
9. Don’t pessimize prematurely. 18
10. Minimize global and shared data. 19
11. Hide information. 20
12. Know when and how to code for concurrency. 21
13. Ensure resources are owned by objects. Use explicit RAII and smart pointers. 24

Coding Style
14. Prefer compile- and link-time errors to run-time errors. 28
15. Use const proactively. 30
16. Avoid macros. 32
17. Avoid magic numbers. 34
18. Declare variables as locally as possible. 35
19. Always initialize variables. 36
20. Avoid long functions. Avoid deep nesting. 38
21. Avoid initialization dependencies across compilation units. 39
22. Minimize definitional dependencies. Avoid cyclic dependencies. 40
23. Make header files self-sufficient. 42
24. Always write internal #include guards. Never write external #include guards. 43

Functions and Operators
25. Take parameters appropriately by value, (smart) pointer, or reference. 46
26. Preserve natural semantics for overloaded operators. 47
27. Prefer the canonical forms of arithmetic and assignment operators. 48
28. Prefer the canonical form of ++ and --. Prefer calling the prefix forms. 50
29. Consider overloading to avoid implicit type conversions. 51
30. Avoid overloading &&, ||, or , (comma) . 52
31. Don’t write code that depends on the order of evaluation of function arguments. 54

Class Design and Inheritance
32. Be clear what kind of class you’re writing. 56
33. Prefer minimal classes to monolithic classes. 57
34. Prefer composition to inheritance. 58
35. Avoid inheriting from classes that were not designed to be base classes. 60
36. Prefer providing abstract interfaces. 62
37. Public inheritance is substitutability. Inherit, not to reuse, but to be reused. 64
38. Practice safe overriding. 66
39. Consider making virtual functions nonpublic, and public functions nonvirtual. 68
40. Avoid providing implicit conversions. 70
41. Make data members private, except in behaviorless aggregates (C-style structs). 72
42. Don’t give away your internals. 74
43. Pimpl judiciously. 76
44. Prefer writing nonmember nonfriend functions. 79
45. Always provide new and delete together. 80
46. If you provide any class-specific new, provide all of the standard forms (plain, in-place, and nothrow). 82

Construction, Destruction, and Copying
47. Define and initialize member variables in the same order. 86
48. Prefer initialization to assignment in constructors. 87
49. Avoid calling virtual functions in constructors and destructors. 88
50. Make base class destructors public and virtual, or protected and nonvirtual. 90
51. Destructors, deallocation, and swap never fail. 92
52. Copy and destroy consistently. 94
53. Explicitly enable or disable copying. 95
54. Avoid slicing. Consider Clone instead of copying in base classes. 96
55. Prefer the canonical form of assignment. 99
56. Whenever it makes sense, provide a no-fail swap (and provide it correctly). 100

Namespaces and Modules
57. Keep a type and its nonmember function interface in the same namespace. 104
58. Keep types and functions in separate namespaces unless they’re specifically intended to work together. 106
59. Don’t write namespace usings in a header file or before an #include. 108
60. Avoid allocating and deallocating memory in different modules. 111
61. Don’t define entities with linkage in a header file. 112
62. Don’t allow exceptions to propagate across module boundaries. 114
63. Use sufficiently portable types in a module’s interface. 116

Templates and Genericity
64. Blend static and dynamic polymorphism judiciously. 120
65. Customize intentionally and explicitly. 122
66. Don’t specialize function templates. 126
67. Don’t write unintentionally nongeneric code. 128

Error Handling and Exceptions
68. Assert liberally to document internal assumptions and invariants. 130
69. Establish a rational error handling policy, and follow it strictly. 132
70. Distinguish between errors and non-errors. 134
71. Design and write error-safe code. 137
72. Prefer to use exceptions to report errors. 140
73. Throw by value, catch by reference. 144
74. Report, handle, and translate errors appropriately. 145
75. Avoid exception specifications. 146

STL: Containers
76. Use vector by default. Otherwise, choose an appropriate container. 150
77. Use vector and string instead of arrays. 152
78. Use vector (and string::c_str) to exchange data with non-C++ APIs. 153
79. Store only values and smart pointers in containers. 154
80. Prefer push_back to other ways of expanding a sequence. 155
81. Prefer range operations to single-element operations. 156
82. Use the accepted idioms to really shrink capacity and really erase elements. 157

STL: Algorithms
83. Use a checked STL implementation. 160
84. Prefer algorithm calls to handwritten loops. 162
85. Use the right STL search algorithm. 165
86. Use the right STL sort algorithm. 166
87. Make predicates pure functions. 168
88. Prefer function objects over functions as algorithm and comparer arguments. 170
89. Write function objects correctly. 172

Type Safety
90. Avoid type switching; prefer polymorphism. 174
91. Rely on types, not on representations. 176
92. Avoid using reinterpret_cast. 177
93. Avoid using static_cast on pointers. 178
94. Avoid casting away const. 179
95. Don’t use C-style casts. 180
96. Don’t memcpy or memcmp non-PODs. 182
97. Don’t use unions to reinterpret representation. 183
98. Don’t use varargs (ellipsis). 184
99. Don’t use invalid objects. Don’t use unsafe functions. 185
100. Don’t treat arrays polymorphically. 186
Bibliography (7 pages)
Summary of Summaries (13 pages)
Index (12 pages)
источник: http://www.gotw.ca/publications/c++cs.htm