改进代码的指导原则

我个人的一些最爱:

努力编写符合要求的代码 const correct . 您将使用编译器来帮助清除容易修复但有时会带来痛苦的bug。您的代码还将讲述您在编写它时的想法——一旦您离开,对于新手或维护人员来说很有价值。

退出内存管理业务。学习使用智能指针: std::auto_ptr , std::tr1::shared_ptr (或 boost::shared_ptr )及 boost::scoped_ptr . 了解它们之间的差异以及何时使用它们。

您可能会使用标准模板库。阅读 Josuttis book . 不要在读完容器的前几章后就认为你了解STL。深入到好东西:算法和函数对象。

1. 删除不必要的代码。

仅此而已。

• 使用并实施通用的编码样式和准则。 理论基础: 团队中或公司中的每个开发人员都能够阅读代码,而不会因不同的支架样式或类似样式而分心。
• 定期对整个源代码库进行完整重建(即每天进行构建或每次签入后进行构建),并报告任何错误! 源代码几乎总是处于可用状态,问题在“实现”后很快就会被检测到,解决问题的成本很低。

打开编译器中可以出现的所有警告(gcc: -Wall 这是一个很好的开始,但不包括所有内容,因此请检查文档),并使其出错,以便您必须修复它们(gcc: -Werror ).

其中一个答案中提到的谷歌的风格指南非常可靠。这里面有一些毫无意义的东西,但它是好的多于坏的。

.

下面是一些来自lil'ole me的一般提示:

1. 您的缩进和括号样式都是错误的。其他人的也是。因此,请遵循该项目的标准。放下你的自尊心,设置你的编辑器,使所有的东西都尽可能与代码库的其余部分保持一致。阅读缩进不一致的代码真的很烦人。也就是说,括号和缩进与“改进代码”毫无关系,更多的是提高与他人合作的能力。

2. 评论得好。这是非常主观的,但总的来说,写评论总是好的 为什么? 代码按照它的方式工作,而不是解释它的功能。当然,对于复杂的代码来说,对于那些可能不熟悉算法或代码的程序员来说,这也是一件好事 什么 它也做得很好。非常欢迎链接到所用算法的描述。

3. 以尽可能简单的方式表达逻辑。具有讽刺意味的是,像“将常数放在比较的左侧”这样的建议在这里出现了错误,我认为。它们很受欢迎,但对于说英语的人来说,它们经常打破节目对阅读者的逻辑流程。如果您不能相信自己(或您的编译器)能够正确地编写相等比较,那么请务必使用这样的技巧。但你这样做是在牺牲清晰度。同样属于这一类的还有。。。“我的逻辑是否有3级缩进?是否更简单?”并将类似的代码滚动到函数中。甚至可以拆分函数。编写优雅地表达底层逻辑的代码需要经验,但值得一试。

那是相当普遍的。对于具体的建议,我没有比萨特和亚历山德雷斯库做得更好的了。

if( 12 == var )

不

if( var == 12 )

因为如果您未键入“=”则它将成为赋值。在最上面的版本中,编译器说这是不可能的,在后面的版本中它运行,if总是true。

当if不在同一行时,我会使用大括号表示。

if( a == b ) something();
if( b == d )
{
    bigLongStringOfStuffThatWontFitOnASingleLineNeatly();
}

打开和关闭大括号总是有自己的行。但这当然是个人习惯。

不要注释掉不再使用的代码。如果要恢复旧代码,请使用源代码管理系统。注释掉代码只会使事情看起来很混乱,并使您的注释实际上很重要,逐渐消失在注释代码的背景混乱中。

3. 获得Scott Meyer的书,有效的C++
4. 获取史蒂夫·麦康奈尔的书《代码完成》的副本。

还有一个不错的 C++ Style Guide 谷歌内部使用,包括这里提到的大部分规则。

开始写很多注释——但要以此为契机重构代码,使其不言自明。

即:

for(int i=0; i<=arr.length; i++) {
  arr[i].conf() //confirm that every username doesn't contain invalid characters
}

for(int i=0; i<=activeusers.length; i++) {
  activeusers[i].UsernameStripInvalidChars()
}

• 使用制表符进行缩进,但将数据与空格对齐 这意味着人们可以通过改变制表符的大小来决定缩进多少,但也可以保持对齐(例如,当为结构赋值时,您可能希望所有的“=”都在垂直线上)

• 在可能的情况下,总是使用常量或内联函数而不是宏

• 不要在头文件中使用“using”,因为包含该heafer的所有内容也会受到影响,即使包含您头文件的人不希望所有std(例如)都位于其全局命名空间中。

• 如果某物的长度超过80列,将其分成多行,例如

  if(SomeVeryLongVaribleName != LongFunction(AnotherVarible, AString) &&
     BigVaribleIsValid(SomeVeryLongVaribleName))
  {
      DoSomething();
  }
  

• 只有重载运算符才能使它们执行用户期望的操作,例如重载2dVector的+和-运算符就可以了

1. 设置编码约定,并让所有相关人员遵守约定(您不希望阅读要求您找出下一个语句/表达式的位置的代码,因为它没有正确缩进)
2. 不断地重构代码(获取一份Martin Fowler的《重构》,书中详细介绍了优缺点)
3. 编写松散耦合的代码(通过编写自我解释的代码避免编写注释,松散耦合的代码往往更易于管理/适应更改)
4. 如果可能的话,单元测试你的代码(或者如果你有足够的男子气概,TDD)
5. 提早释放,经常释放

类似地,您可能会在此处找到一些有用的建议: How do you make wrong code look wrong? What patterns do you use to avoid semantic errors?

在可能的情况下,使用预增量而不是后增量。

我在我的C++项目中使用PC Link,特别是它如何引用现有出版物,例如MISRA指南或Scott Meyers的“有效C++”和“更有效的C++”。即使您计划为静态分析工具检查的每个规则编写非常详细的理由,也最好指向用户信任的已建立的出版物。

这是C++大师所给出的最重要的建议,它帮助我在一些关键的场合找到代码中的错误:

• 不应该 来修改对象。
• 当对象为空时,在参数中使用常量引用和指针 不应该 来修改对象。

有了这两条规则,编译器将免费告诉您代码中的逻辑哪里有缺陷!

此外,对于一些好的技巧,您可能会遵循 Google's blog "Testing on the Toilet" .

六个月后再看

确保正确缩进

我并不是在为自己寻找建议——我正在编写一个静态代码分析工具(目前的商业产品对于我想要的东西来说还不够好),我正在寻找插件的想法,以突出代码中可能存在的错误。

智能指针有一种很好的方法可以非常清楚地指示所有权。如果您是一个类或函数:

• 如果你得到一个 原始指针
• 如果你得到一个 ,您不拥有指针对象,而且指针对象可以随时消失。
• 如果你得到一个 共享ptr
• 如果你得到一个 自动检查

我发现auto_ptr的情况尤其明显:在设计中,如果我看到auto_ptr,我立即知道该对象将从系统的一部分“漂移”到另一部分。

这至少是我在我的宠物项目中使用的逻辑。我不确定这个主题会有多少变化,但到目前为止,这个规则集对我很有用。