关于代码质量的简单思考

2.62/5 (12投票s)

2008年9月25日

4分钟阅读

14449

对于软件本身，通过测量其性能、内存使用量、bug 数量等来讨论其质量更容易。但是，如果谈论代码文件，我们如何编写让我们引以为豪的代码？

引言

对于软件本身，通过测量其性能、内存使用量、bug 数量等来讨论其质量更容易。但是，如果谈论代码文件，我们如何编写让我们引以为豪的代码？

以下是一些衡量代码质量的主题

可以将许多其他主题添加到此列表中以进行代码质量衡量。但我们现在将重点关注这五个方面。

可能你已经见过像下面这样非常“聪明”的代码

  public static int GetNextSize(int i)
  {
    //multiply it by four and make sure it is positive
    return i > 0 ? i  << 2 : ~(i << 2) + 1;
  }

至少我们有一行注释；好吧，我们稍后会讨论注释。但是如你所见，你确实应该在理解代码的作用之前集中精力并评估代码。因此，以这种方式隐藏代码，尤其是在团队中工作时，会给你的团队成员带来很大的麻烦，并且过一段时间后，也会给你带来麻烦。代码应该始终清晰透明，就像下面这样

 public static int GetNextSize(int i)
  {
    return Math.Abs(i * 4);  
  }

根据 Steve McConnell 的说法

“好的代码本身就是最好的文档。”

一些开发人员为他们的大量代码行数感到自豪，因为这证明了项目有多大。但另一方面，这不是真的，因为更多的代码行意味着更多的复杂性，更难维护的代码库，甚至更糟；对象方向或代码重用的错误实现。

如果你考虑两个功能相同的软件，结构良好的软件始终具有较少的代码行。代码行数较少的那个更容易维护和修复 bug。这意味着越轻越好。

让我引用比尔·盖茨的话

“用代码行数来衡量编程进度就像用重量来衡量飞机制造进度”。

当然，快速运行的程序比其慢速版本更好，并且性能考虑始终处于开发过程的前沿。但是，将清晰可读的代码更改为其复杂且快速的等效行并不总是明智的主意，并且总有一种方法可以以更清晰的方式实现相同的算法。

好吧，我并不是说不要考虑性能优化，但是始终有更大的机会优化整个系统。更重要的是关注大局并解决系统范围内的性能问题，或者重构代码以便可以更快地进行更改，而不是解决单行代码中的性能问题……除非，当然，该行代码被调用了数百万次。

同样，我很确定你已经见过很多没有注释或注释不足的代码。即使代码本身是可读的或不可读的，注释也是重要的物质。你应该始终记住编写清晰的注释，就像你告诉别人一样。不要用你的语言输入它们，而用一种通用语言。

尽管我们只是专注于代码质量（而不是架构或软件质量），但我们需要讨论异常管理。任何意外情况都可能导致异常。通常，新开始的开发人员会直接找到解决方案，但不愿考虑他们的解决方案中可能发生的任何异常情况。因此，任何缺失的控制或直接假设都可能导致你的应用程序崩溃。

在最坏的情况下（可能也是最简单的），你可以在应用程序域级别捕获任何异常，并显示一个通用错误消息屏幕。但在任何情况下，你都不应该让你的软件崩溃！

正如你已经意识到的那样，平衡并找到最正确的编码方式真的不容易。如果你不喜欢你编写的代码，退后一步，审查它，修复它，重构它，直到你为它感到自豪。在早期阶段修复问题将在长期内带来巨大的回报。寻找完美的代码将引导你更好地理解你正在做的事情。

还有一句来自 Martin Fowler 的话

“任何傻瓜都可以编写计算机可以理解的代码。优秀的程序员编写人类可以理解的代码。”