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

Question

你好

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

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

Answer 1

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

您可能想要了解的另一个资源是C++编码标准: Herb Sutter和Andrei Alexandrescu的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()) ....

这个标准的问题一直存在.
所以不要使用它.