Question

你好

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

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

Answer 1

快速浏览一下，大多数事情看起来都不错。引起我注意的一件事是我并不真正赞同的是他在那里提出的一些命名惯例，但是用一种一致的方式命名事物的概念已经死了。

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

Answer 2

关于霍夫：

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

即使对于有视力的人来说，这些InitialCaps标识符也难以阅读。对此有多种人为因素研究。 WordsSeparatedByInitialCaps对于人们来说更难阅读，即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。如果您要维护旧代码，请不要更改它，除非需要更改。

他的建议不是将布尔与真实比较是正确的。解决方案不是将布尔值与假（或更差if (FALSE != func()) ...）进行比较。解决方案不是将布尔值与任何东西进行比较：if (func()) ...。

此标准的问题不断发生。
所以不要使用它。

你会推荐Todd Hoff的C ++ Coding Standard吗？

2 个答案: