Стандарты программирования на С++. 101 правило и рекомендация

• Предисловие

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

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

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

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

• Проектирование классов и наследование
• 32. Ясно представляйте, какой вид класса вы создаете
• 33. Предпочитайте минимальные классы монолитным
• 34. Предпочитайте композицию наследованию
• 35. Избегайте наследования от классов, которые не спроектированы для этой цели
• 36. Предпочитайте предоставление абстрактных интерфейсов
• 37. Открытое наследование означает заменимость. Наследовать надо не для повторного использования, а чтобы быть повторно использованным
• 38. Практикуйте безопасное перекрытие
• 39. Виртуальные функции стоит делать неоткрытыми, а открытые — невиртуальными
• 40. Избегайте возможностей неявного преобразования типов
• 41. Делайте данные-члены закрытыми (кроме случая агрегатов в стиле структур С)
• 42. Не допускайте вмешательства во внутренние дела
• 43. Разумно пользуйтесь идиомой Pimpl
• 44. Предпочитайте функции, которые не являются ни членами, ни друзьями
• 45. new и delete всегда должны разрабатываться вместе
• 46. При наличии пользовательского new следует предоставлять все стандартные типы этого оператора

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

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

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

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

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

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

• Безопасность типов
• 90. Избегайте явного выбора типов — используйте полиморфизм
• 91. Работайте с типами, а не с представлениями
• 92. Избегайте reinterpret_cast
• 93. Избегайте применения static_cast к указателям
• 94. Избегайте преобразований, отменяющих const
• 95. Не используйте преобразование типов в стиле С
• 96. Не применяйте memcpy или memcmp к не-POD типам
• 97. Не используйте объединения для преобразований
• 98. Не используйте неизвестные аргументы (троеточия)
• 99. Не используйте недействительные объекты и небезопасные функции
• 100. Не рассматривайте массивы полиморфно

• Список литературы

• Резюме из резюме