Скотт Мейерс. Эффективное использование С++

 На этот раз речь пойдет о замечательной книге Скотта Мейерса “Эффективное использование С++”. И хотя возможно эта книга (и цитаты из нее, соответственно) будут более интересны разработчикам, которые в своей профессиональной деятельности занимаются языком программирования С++, многие идеи положенные в основу некоторых правил будут актуальны и для разработчиков из других областей.

Мое развернутое мнение, в виде рецензии, можно почитать на моем блоге, а также на сайте rsdn.ru.

Независимо от вида ресурсов, важно, чтобы по окончании использования они были освобождены.
Попытки обеспечить это "вручную" представляет сложность при любых условиях, но если принять во внимание исключения, функции со многими путями возврата и приложения, модифицируемое программистами без отчетливого понимания последствий вносимых изменений, то становится ясно, что придумывать в каждом случае особый способ управления ресурсами нежелательно.
Глава 3. Управление ресурсами

Любой интерфейс, который требует, чтобы пользователь что-то помнил, может быть использован неправильно, ибо пользователь вполне способен забыть, что от него требуется.
Правило 18. Проектируйте интерфейсы так, что их легко было использовать правильно и трудно – неправильно

Женщина либо беременна, либо нет. Невозможно быть чуть-чуть беременной. Аналогично программная система является либо безопасной по исключениям, либо нет. Нет такого понятия, как частично безопасная система. Если система имеет всего одну небезопасную относительно исключений функцию, то она небезопасна и в целом, потому что вызов этой функции может привести к утечке ресурсов и повреждению структур данных. К несчастью, большинство унаследованного кода на С++ было написано без учета требований безопасности исключений, поэтому многие системы на сегодня являются в этом отношении небезопасными. Они включают код, написанный в небезопасной манере.
Правило 29. Стремитесь, чтобы программа была безопасна относительно исключений

Сорок лет назад код, изобилующий операторами goto, считался вполне приемлемым. Теперь же мы стараемся писать структурированные программы. Двадцать лет назад глобальные данные ни у кого не вызывали возражений. Теперь мы стремимся данные инкапсулировать. Десять лет назад написание функций без учета влияния исключений было нормой. А сейчас мы боремся за достижение безопасности относительно исключений.
Времена меняются. Мы живем. Мы учимся.
Правило 29. Стремитесь, чтобы программа была безопасна относительно исключений

Не забывайте об эмпирическом правиле "80-20", которое утверждает, что типичная программа тратит 80% времени на исполнение 20% кода. Это важное правило, поскольку оно напоминает, что цель разработчика программного обеспечения - идентифицировать те 20% кода, которые действительно способны повысить производительность программы. Можно до бесконечности оптимизировать и объявлять функции inline, но все это будет пустой тратой времени, если только вы не сосредоточите усилия на нужных функциях.
Правило 30. Тщательно обдумывайте использование встроенных функций

Делая класс D закрытым наследником класса B, вы поступаете так потому, что заинтересованы в использовании некоторого кода, уже написанного для B, а не потому, что между объектами B и D существует некая концептуальная взаимосвязь. Таким образом, закрытое наследование - это исключительно прием реализации. Можно сказать, что закрытое наследование означает наследование одной только реализации, без интерфейса. Если D закрыто наследует B, это означает, что объекты D реализованы посредством объектов B, и ничего больше. Закрытое наследование ничего не означает в ходе проектирования программного обеспечения и обретает смысл только на этапе реализации.
Правило 39. Продумывайте подход к использованию закрытого наследования

P.S. Спасибо Алексею Ершову за идею цитат из этой замечательной книги, и за отличную цитату об эволюции в области разработки ПО (вторая цитат из правила 29).