你能推荐Todd Hoff的C++编码标准吗

Would you recommend C++ Coding Standard by Todd Hoff?

本文关键字：C++ 编码 标准 Hoff Todd      更新时间：2023-10-16

Hallo

目前我正在寻找一个好的C++编码标准，我可以坚持下去。在互联网上我可以找到很多编码标准。有些规则在大多数情况下都很常见。但也存在差异。我找到了Todd Hoff的C++编码标准(http://www.maultech.com/chrislott/resources/cstyle/CppCodingStandard.html)。我看了一眼，发现它真的很棒。他不仅给出了一些常见的规则，还详细介绍了细节。名称约定就是一个很好的例子。

我想知道，如果有人使用这个C++编码标准，他会建议使用还是不使用它？

关于Hoff：

可怕的命名约定
命名约定非常不标准。在我工作过的大多数地方和我研究过的大多数约定中，成员函数和成员数据都遵循相同的规则：所有小写单词用下划线分隔。

即使对于视力正常的人来说，这些InitialCaps标识符也很难读取。已有多种人为因素对此进行了研究。WordsSseparatedByInitialCaps对人们来说更难阅读，也就是words_separated_by_underscores。对于视力受损的人来说，InitialCaps的使用比毫无价值更糟糕。在我有影响力的编码标准中，InitialCaps用于类名，并且仅用于类名。

ALL_CAPS比InitialCaps更难读取。每一份法律合同都有一些真正重要的法律条款，律师们更希望我们掩盖和忽视这些条款。那些重要的条款很容易找到：它们都是大写的。对于视力正常的人来说，所有大写的文字都很难阅读。这就是为什么律师喜欢使用它。我们应该尽可能避免使用ALL_CAPS。仅为宏保留ALL_CAPS，切勿定义非ALL_CAPS的宏。这最大限度地减少了主处理器名称和标识符之间的冲突。

匈牙利的记法很糟糕，即使它只是部分使用。

违反RAII
这些标准违反了RAII。也就是说（重点是我的）：

不要在对象的构造函数中做任何实际的工作。在构造函数内部，只初始化变量和/或只执行不会失败的操作。为完成构造的对象创建一个Open（）方法Open（）应该在对象实例化后调用。

关于析构函数的非常糟糕的建议
关于析构函数的建议和关于构造函数的建议一样糟糕。

小心在析构函数中抛出异常

真的吗？"不要在析构函数中抛出异常"怎么样

本节的更多内容，

必须特别注意捕捉对象销毁过程中可能出现的异常。当一个对象抛出异常时，还必须特别注意完全销毁它。

究竟有人会怎么做呢？简单的答案是正确的：不要在析构函数中抛出异常。曾经

这真是太可怕了

/////////////////////////////// PUBLIC ///////////////////////////////////////
//============================= LIFECYCLE ====================================
XX::XX()
{
}// XX
XX::XX(const XX&)
{
}// XX
XX::~XX()
{
}// ~XX

//============================= OPERATORS ====================================
XX& 
XX::operator=(XX&);
{
   return *this;
}// =
//============================= OPERATIONS ===================================
//============================= ACESS      ===================================
//============================= INQUIRY    ===================================
/////////////////////////////// PROTECTED  ///////////////////////////////////
/////////////////////////////// PRIVATE    ///////////////////////////////////

那个愚蠢的（6==errorNum）垃圾
我讨厌那种结构。它很丑，本末倒置。在这里，正确的做法是要求代码在-Wall或更严格的条件下编译干净，并使用代码分析器来捕捉编译器找不到/找不到的其他问题。不要让我写东西，因为二十年前有个白痴写了if (errorNum = 6) ...。

布尔类型的布尔
这一节的标题是正确的：这是牛市。他写的东西既过时又错误。如果您正在编写新代码，请使用bool。如果您正在维护旧代码，除非需要更改，否则不要更改它。

他的建议是不要把布尔值与真值相比较，这是正确的。解决方案不是将布尔值与false（甚至更糟的if (FALSE != func()) ...）进行比较。解决方案是不将布尔值与任何内容进行比较：if (func()) ...。

此标准的问题一直存在。
所以不要使用它。

快速浏览一下，它在大多数方面看起来都不错。有一件事引起了我的注意，我并不完全同意他在其中提出的一些命名约定，但用一致的方式命名的概念已经过时了

您可能想查看的另一个资源是Herb Sutter和Andrei Alexandrescu的《C++编码标准：101规则、指南和最佳实践》。它不像Todd Hoff的那样具体，但它确实提供了更多关于为什么特定规则应该成为编码标准的一部分的讨论。

相关文章：