Используйте вспомогательные библиотеки там, где это уместно
Причина
Использование хорошо спроектированной, хорошо документированной и хорошо поддерживаемой библиотеки экономит время и усилия; её качество и документация, скорее всего, будут лучше, чем то, что вы могли бы сделать сами, если большую часть времени нужно тратить на реализацию. Стоимость (время, усилия, деньги и т.д.) библиотеки может быть разделена между многими пользователями. Широко используемая библиотека с большей вероятностью будет поддерживаться в актуальном состоянии и портироваться на новые системы, чем отдельное приложение. Знание широко используемой библиотеки может сэкономить время в других/будущих проектах. Итак, если подходящая библиотека существует для вашей прикладной области, используйте её.
Пример
std::sort(begin(v), end(v), std::greater<>());
Если только вы не эксперт в алгоритмах сортировки и у вас нет достаточно времени, это с большей вероятностью будет корректным и будет работать быстрее, чем всё, что вы напишете для конкретного приложения. Вам нужна причина не использовать стандартную библиотеку (или любые базовые библиотеки, которые использует ваше приложение), а не причина использовать её.
Примечание
По умолчанию используйте
Примечание
Если для важной области не существует хорошо спроектированной, хорошо документированной и хорошо поддерживаемой библиотеки, возможно, вам следует спроектировать и реализовать её, а затем использовать.
I: Интерфейсы
Интерфейс — это контракт между двумя частями программы. Точное указание того, что ожидается от поставщика услуги и пользователя этой услуги, существенно. Наличие хороших (понятных, поощряющих эффективное использование, не подверженных ошибкам, поддерживающих тестирование и т.д.) интерфейсов — вероятно, самый важный единственный аспект организации кода.
Краткое содержание правил интерфейсов:
- I.1: Делайте интерфейсы явными
- I.2: Избегайте не-
constглобальных переменных - I.3: Избегайте синглтонов
- I.4: Делайте интерфейсы точно и строго типизированными
- I.5: Указывайте предусловия (если они есть)
- I.6: Предпочитайте
Expects()для выражения предусловий - I.7: Указывайте постусловия
- I.8: Предпочитайте
Ensures()для выражения постусловий - I.9: Если интерфейс является шаблоном, документируйте его параметры с помощью концептов
- I.10: Используйте исключения для сигнализации о невозможности выполнить требуемую задачу
- I.11: Никогда не передавайте владение через сырой указатель (
T*) или ссылку (T&) - I.12: Объявляйте указатель, который не должен быть null, как
not_null - I.13: Не передавайте массив как единственный указатель
- I.22: Избегайте сложной инициализации глобальных объектов
- I.23: Сохраняйте небольшое количество аргументов функции
- I.24: Избегайте соседних параметров, которые могут быть вызваны с теми же аргументами в любом порядке с разным смыслом
- I.25: Предпочитайте пустые абстрактные классы в качестве интерфейсов иерархиям классов
- I.26: Если вам нужен межкомпиляторный ABI, используйте подмножество в стиле C
- I.27: Для стабильного ABI библиотеки рассмотрите идиому Pimpl
- I.30: Инкапсулируйте нарушения правил
Смотрите также: