《Design by Contract for Embedded Software》翻译( 八 ) _生活百科

Assertions in Production Code产品代码中的断言
The standard practice is to use assertions during development and testing, but to disable them in the final product by defining the NDEBUG macro. In Listing 1, I have replaced this macro with NASSERT, because many development environments define NDEBUG automatically when you switch to the production version, and I wanted to decouple the decision of disabling assertions from the version of software that you build. That’s because I truly believe that leaving assertions enabled, especially in the ship-version of the product, is a good idea.

标准做法是在开发和测试期间使用断言，但在最终产品中通过定义 NDEBUG 宏来禁用它们。在清单 1 中，我用 NASSERT 代替了这个宏，因为许多开发环境在你切换到生产版本时自动定义了 NDEBUG，我想把禁用断言的决定与你构建的软件版本脱钩。这是因为我真的相信，让断言处于启用状态，特别是在产品的出货版本中，是一个好主意。

The often-quoted opinion in this matter comes from C.A.R. Hoare, who considered disabling assertions in the final product like using a lifebelt during practice, but then not bothering with it for the real thing. I find the comparison of assertions to fuses more compelling. Would you design a prototype board with carefully rated fuses, but then replace them all with 0 W resistors (chunky pieces of wire) for a production run?

在这个问题上经常被引用的意见来自C.A.R.Hoare，他认为在最终产品中禁用断言就像在练习中使用救生圈，但在真正的比赛中却不屑于使用它。我发现把断言比作保险丝更有说服力。你会用精心设计的保险丝来设计一个原型板，但在生产过程中把它们全部换成 0W 的电阻（大块的电线）吗？

The question of shipping with assertions really boils down to two issues. First is the overhead that assertions add to your code. Obviously, if the overhead is too big, you have no choice. (But then I must ask how have you built and tested your firmware?) However, assertions should be considered an integral part of the firmware and properly sized hardware should accommodate them. As the price of hardware rapidly drops and its capabilities skyrocket, it just makes sense to trade a small fraction of the raw CPU horsepower and memory resources for better system integrity. In addition, as I mentioned earlier, assertions often pay for themselves by eliminating reams of defensive code.

使用断言的问题实际上可以归结为两个问题。首先是断言给你的代码带来的开销。很明显，如果开销太大，你就没有选择。(但是，我必须问，你是如何建立和测试你的固件的？）然而，断言应该被认为是固件的一个组成部分，适当大小的硬件应该容纳它们。随着硬件价格的迅速下降和能力的急剧上升，用一小部分原始 CPU 马力和内存资源来换取更好的系统完整性是有意义的。此外，正如我前面提到的，断言往往通过消除大量的防御性代码而得到回报。

The other issue is the correct system response when an assertion fires in the field. As it turns out, a simple system reset is for most embedded devices the least inconvenient action from the user’s perspective—certainly less inconvenient than locking up a device and denying service indefinitely. That’s exactly what happened the other day, when my wife’s cellular phone froze and the only way of bringing it back to life was to pull out the battery. (I don’t know how she does it, but since then she managed to hang her phone again more than once, along with our VCR and even the TV.) The question that comes to my mind is whether the firmware in those products used assertions (or whether the assertions have been enabled)—apparently not, because otherwise the firmware would have reset automatically.

另一个问题是当一个断言在现场发生时的正确系统响应。事实证明，对于大多数嵌入式设备来说，从用户的角度来看，简单的系统重置是最不方便的行动--当然比锁定设备和无限期拒绝服务要不方便。这正是前几天发生的事情，当时我妻子的手机冻结了，而使其恢复正常的唯一方法是拔出电池。(我不知道她是怎么做到的，但从那时起，她又设法不止一次地把手机挂起来，还有我们的录像机，甚至电视）。我想到的问题是，这些产品的固件是否使用了断言（或断言是否已被启用）--显然没有，因为否则固件会自动重置。

Further ReadingAssertions have been a recurring subject of many articles (and rightly so). For example, two articles from the