除了“将警告视为错误”并修复内存泄漏之外,我们还应该将其他想法作为编码标准的一部分来实现?

时间:2009-11-05 15:13:31

标签: coding-style warnings

首先让我说,我不是编码员,但我帮助管理编码团队。团队中没有人有超过5年的经验,而且他们中的大多数只为这家公司工作过..所以我们有点盲目,因此问题。

我们正在努力使我们的软件更加稳定,并且正在寻求实施一些“最佳实践”和编码标准。最近我们开始认真对待这一点,因为我们确定我们产品中的大部分不稳定性可以与我们允许警告在编译时无需修复的事实相关联。我们也从不打扰认真对待内存泄漏。

在阅读本网站时,我们正在迅速解决我们团队的这个问题,但它引出了一个问题,我们可以在团队范围内实施哪些其他实践来帮助我们?

编辑:我们使用C ++中的跨平台Mac / Windows做相当复杂的2D / 3D图形软件。

17 个答案:

答案 0 :(得分:10)

通常,编码标准/过程中的精确度/严格程度直接与所需的安全级别相关联。例如,如果您在航空航天领域工作,您将严格控制几乎所有事物。但是,另一方面,如果你正在开发一个电脑游戏论坛网站...如果有什么东西坏了,没什么大不了的。你可以有slop。所以YMMV,取决于你的领域。

编码的经典书籍是Steve McConnell的Code Complete第2版。有团队副本和强烈建议您的开发人员购买它(或让公司为他们购买)。这将满足大约70%的风格问题。 CC解决了大多数开发案例。

编辑:

图形软件,C ++,Mac / Windows。

由于您正在进行跨平台工作,会建议您为Mac(10.4(可能),10.5,10.6)和Windows自动执行“check-on-checkin”流程(XP(也许),Vista,7)。这可以确保您的软件编译最少,而且您知道什么时候不编译。

您的源代码控制(您 使用,我认为)应支持分支,您的分支策略也可以反映跨平台性。拥有主线分支,开发分支和实验分支也是有利的。因人而异;您可能需要对此进行迭代,并咨询熟悉配置管理的人员。

由于它是C ++,您可能希望运行Valgrind或类似的,以了解是否存在内存泄漏。你可以得到一些静态分析器:我不知道它们在现代C ++习语中的效果如何。您还可以投资编写一些包装器来帮助观察内存分配。

关于C ++ ......有效的C ++,更有效的C ++和有效的STL(全部来自Scott Meyers)应该放在某人的架子上,以及Andrescu的Modern C ++。你可能会发现Lippman关于C ++对象模型的书很有用,我不知道。

HTH。

答案 1 :(得分:6)

有很多顾问/公司有编码规则要卖给你,你应该没有困难找到一个。然而,一个不首先问你所在领域的人(你在问题中没有提到它)就是为你提供蛇油。

答案 2 :(得分:4)

让每个人阅读并讨论各种标准和指南。我(以及Stroustrup)建议Joint Strike Fighter coding standards。请您的开发人员将其中的指南分类

  • 已经见过
  • 可以轻松满足(当前条件下的一些变化)
  • 应该使用旧代码并遵循新的开发
  • 不值得

进行长时间的技术讨论,并确定团队采用的一套。

答案 3 :(得分:4)

Test-Driven Development。 TDD有助于在开发阶段检查逻辑错误。

答案 4 :(得分:3)

鉴于这是Stack Overflow,有人应该引用The Joel Test。我希望尽可能自动化,因此使用Lint也是必须的。

答案 5 :(得分:3)

代码审查已经证明可以为代码质量带来显着的好处,甚至比传统测试还要好。我建议养成执行常规设计和代码审查的习惯;执行审核的阶段数,审核的正式性和详细程度,以及需要审核的工作百分比都可以根据您的业务需求进行设置。编码标准在正确完成时非常有用(如果每个人的代码看起来相似,也更容易查看),但是你放置括号以及缩进块的距离并不会影响缺陷率。

此外,值得您和您的同行熟悉技术债务的概念,并在您与他们联系时,一点一点地重新设计和改进系统的各个部分。但是,除非您进行全面的单元测试和/或流程以确保高代码质量,否则这可能无济于事。

答案 6 :(得分:2)

您没有提及任何语言,虽然大多数编码标准都与语言无关,但它也可以帮助您进行搜索。在我工作的大多数公司中,他们对不同的编程语言有不同的编码标准。所以我的建议是:

  • 选择您的语言
  • 搜索网络,因为您的语言有很多标准
  • 收集您找到的所有标准
  • 将您的团队分成小组,并给他们一些文件进行分析。他们应该列出他们认为值得在新标准中使用的东西。
  • 召开会议,以便每个小组向每个人展示其调查结果(小组之间会有很多冗余)。这应该是一个公开的讨论,应该考虑每个人的意见。
  • 编制大多数编码人员选择的标准清单,这应该是您的起点。
  • 对标准进行半年度审核,添加或删除内容。

现在,这背后的逻辑是:从头开始编写标准的大多数问题都是开发人员的接受。我们每个人都有办法做事,当外面的人认为一种做事方式比另一种方式更好时,这种做法很糟糕。因此,如果开发人员了解编码标准的逻辑和目的,那么您就完成了一半的工作。另一件事是标准应该根据公司的需求进行设计和创建。会有一些事情会有意义,有些则没有。通过上述方法,您可以区分这些。另一方面,标准应该能够随着时间的推移而改变,以反映公司的需求,因此编码标准应该是一份活文件。

答案 7 :(得分:2)

在添加编码标准/最佳实践时,您首先需要考虑的是它将对您团队的士气和凝聚力产生的影响。开发人员通常会反对任何强加给他们的做法,即使他们是好主意。必须解决人民问题才能取得成功。

您需要让您的小组参与制定标准并尝试达成共识。也就是说,你永远不会就任何事情达成普遍协议,所以你必须平衡共识并达到标准。我已经看到了一些关于标签与源中空格这么简单的重大战斗。

我在复杂项目中看到的关于C / C ++指南的最好的书是Large Scale C++ Software Design。那本书和Code Complete(这是必读经典)是很好的起点。

答案 8 :(得分:2)

这些基础知识适用于大多数行业或团队规模:

  1. 使用敏捷方法(Scrum就是一个很好的例子)。 http://www3.software.ibm.com/ibmdl/pub/software/rational/web/whitepapers/2003/rup_bestpractices.pdf
  2. 使用测试驱动的开发。 http://www.agiledata.org/essays/tdd.html
  3. 使用一致的编码标准。这是一个示例文档: http://www.dotnetspider.com/tutorials/BestPractices.aspx
  4. 让您的团队熟悉 设计模式。 http://www.dofactory.com/Patterns/Patterns.aspx
  5. 这些基础知识不会出错。在那里建立新的团队成员,他们一直在那里完成。 一旦你有这些人加入团队,我强烈建议结对编程。这是感染最佳实践的人的最佳方式。

    祝你好运!

答案 9 :(得分:1)

如果您决定使用编码标准,您需要非常小心放入的内容。如果文档太长或者专注于任意风格的细节,它将被忽略,没有人会费心去阅读它。编码标准中的许多内容通常只是编写文档的人(或者某些已经从网络上复制过的标准!)的偏好。如果标准中包含某些内容,那么读者需要非常清楚它如何提高质量以及它的重要性。

我认为,使代码可读的大部分内容与设计而不是代码的布局有关。我已经看到很多代码符合标准但仍然难以阅读(真的很长的方法,糟糕的命名等) - 你不能把它的所有标准都用在标准上,在某些方面它归结为技术和训练有素的开发人员 - 尽你所能提高他们的技能。

或许不是编码标准文件,试着让团队了解好的设计(说起来容易做起来难,我知道)。让他们了解SOLID原则,如何分离问题,如何正确处理异常等事情。如果设计得好,代码将易于阅读,如果有足够的白线或花括号在正确的位置,则无关紧要。

获取一些有关设计原则的书籍(请参阅下面的几条建议)。也许让团队做一些研讨会来讨论一些话题。或许让他们集体撰写一份文件,说明哪些原则对他们的项目可能很重要。无论你做什么,都要确保整个团队决定标准/原则是什么。

http://www.amazon.co.uk/Principles-Patterns-Practices-Robert-Martin/dp/0131857258/ http://www.amazon.co.uk/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882

答案 10 :(得分:1)

除了已经推荐的书籍,我还要提一下,

C ++编码标准:Herb Sutter和Andrei Alexandrescu的101条规则,指南和最佳实践(平装 - 2004年11月4日)

答案 11 :(得分:1)

不要从头开始编写自己的标准。

有可能有几个定义了你想要的东西,并且比你自己想出的更完整。也就是说,如果你不同意在小问题上100%同意你不要太担心,你可以交换其他人的某些部分,或者将其中的某些部分称为警告而不是错误 - 取决于你自己的需要。 (例如,如果一条线的长度超过80个字符,某些标准会发出警告,我宁愿不超过120作为硬限制,但会确保有一个很好的理由 - 例如可读性和清晰度 - 如果有> 80)。

此外,请尝试找到根据标准检查代码的自动方法 - 包括您根据需要进行的微小更改。

答案 12 :(得分:1)

如果您的框架需要某些规则才能正常运行,请将其放入编码标准中。

答案 13 :(得分:1)

你应该有一个规则是某种命名标准。它只是让人们的生活更轻松,而不是真正的入侵。

除此之外,我不得不说这取决于你的团队水平。有些人比其他人需要更多规则。人越多,他们对规则的“支持”就越少。

如果您需要一套完整的编码规则来控制每一个细节,那么您将花费大量时间来讨论规则的规则和例外以及您应该编写规则的内容。我会选择已经写好的东西。

如果你关心质量,那么你可以做的一件事就是关于规则,是: 自动化构建和测试。这对我帮助很大。一旦发现问题,创建一个可以编写测试以验证问题的环境确实很有帮助。解决问题,然后轻松将测试添加到自动测试套件中,以确保在没有发现问题的情况下无法返回。 然后确保经常运行。每次有人检查时,最好是。

答案 14 :(得分:1)

此博客文章介绍了mediocre programming的许多常见做法。这些是您团队所面临的一些潜在问题。它包括对每个人的“最佳实践”的快速解释。

答案 15 :(得分:0)

如果您使用VB.NET进行编程,请确保将 Option Explicit Option Strict 设置为ON。这将为你节省很多追踪神秘错误的悲伤。这些可以在项目级别设置,这样您就不必记住在代码文件中设置它们

答案 16 :(得分:0)

我真的很喜欢: MISRA C标准(它有点严格,但是C ++的想法很有用) 和Hi-Integrity的http://www.codingstandard.com/HICPPCM/index.html C ++标准,大量借鉴了MISRA

LDRA(静态分析工具)使用这些标准对您的工作进行评级(我不会因为它的价格昂贵而使用),但我可以保证将cppcheck作为一个好的“免费/免费”静态分析检查程序运行。