你最不喜欢的C++编码准则

对我来说，可能是16。避免使用宏。我发现有很多事情我只能用宏来做（尤其是将__FILE__和__LINE_内联到表达式中），在许多情况下，我需要一个在外部函数上下文中操作的紧凑表达式（例如，检查结果代码并返回）。因此，我的代码倾向于大量地使用宏形式的断言，所以我认为这是一个我经常忽略的断言。

也就是说，如果该语言允许对相同概念进行类似紧凑的替代表达，我会放弃大部分使用，但由于它不允许，宏将存在很长一段时间。

我应该补充一点，这并不是说我认为这个建议不好，或者当你有其他选择时遵循它是不好的。我只是发现我最终使用了很多宏，通常是因为没有其他选择。

我昨天才在这个网站上破坏了19（总是初始化变量）。我的代码片段是：

uint64_t i = getIEEEbitpatternByMeansRelevantToTheQuestion();
double d;
memcpy(&d, &i, 8);

在初始化d时看不到任何意义：没有可能有意义的值，编译器要么忽略我提供的值，要么做一些浪费的事情。

初始化非POD类型和作为类成员的POD类型是非常明智的。初始化一些东西只是为了在上面设置memcpy/memset，而不是太多。

事实上，初始化非POD的原因之一是为了避免稍后在顶部分配的默认构造。初始化一个你打算在上面乱涂乱画的POD基本上也是一件坏事。

不过，我没有这本书，所以这可能就是他们的意思，标题中的"总是"有误导性。

老实说，随着时间的推移，我自然而然地养成了几乎完全符合这些指导方针的习惯。遵循这些类型的编码标准会产生干净、易于维护的代码。

否。56-默认情况下使用矢量。我经常用deque代替。有趣的是，赫伯·萨特本人似乎对此感到矛盾。

恐怕我偶尔会喜欢一个好的c风格演员阵容。（我意识到它的问题-只是无法控制自己）

72。更喜欢使用异常来报告错误

相反，我使用72-ALT。不要抛出异常：）

好吧，除了在发布的代码库的公共API层中报告调用方的前提条件违规之外——并且仅在该层中。

我忽略了其中的大多数，因为它们可以概括为：使用C++，就好像它是一种高级面向对象的语言一样。但是，如果你想要一种高级的面向对象语言，有更好的候选者（C#、Java、Lisp、Python等）。C++本质上是所有结构化宏汇编程序之母，我也这样使用它，而且只在需要它的工作中使用。

在查看了所有规则后，它将是：89。正确写入函数对象。我从不花时间把它们写对。有时我会使用变差函数，但这并不是我的选择。