|嵌入式开发：在C中使用断言的8个技巧( 二 )

断言确实占用了一些代码空间，但更重要的是它们需要几个时钟周期来评估它们的布尔表达式。资源有限的裸机系统可能会因关闭断言而严重影响其执行时间，从而导致生产系统中出现新的错误。开发团队需要决定是否值得承担风险。另一种方法是启用断言并将其输出重定向到系统日志，以便轻松识别任何挥之不去的错误，但可能不建议暂停系统。
技巧6 – 不要让断言产生副作用
assert 的默认实现将允许嵌入式开发人员将可执行代码作为布尔表达式的一部分包含在内。例如，状态变量可以作为传递给 assert 的表达式的一部分来实现。如果传递给 assert 的表达式有副作用，即它改变了嵌入式系统的状态，禁用断言将改变系统的行为。开发人员应确保他们的表达式没有副作用，因为他们可能会在系统中添加睡眠时间错误，该错误只会唤醒生产代码。

技巧7 – 断言应该占代码的1 % — 3%
对于代码库中应该存在多少断言，每个开发人员都有自己的看法。可以商定的一个数字是代码库中断言的百分比应该大于零。断言为开发人员提供了一种在代码库中出现错误时发现错误的好方法。调试是开发嵌入式系统最大的浪费时间和令人沮丧的组件之一。无论开发人员的人数是1%、3%还是5% ，都可以利用断言来发挥自己的优势，让开发嵌入式软件变得更加愉快。如果有的话，我们知道有 0% 不是正确的解决方案!
技巧8 – 使用断言作为可执行代码注释
断言会产生很好的评论!一个写得很好的表达式可以准确地告诉开发人员他们在代码中的给定点应该期望什么。开发人员应该构建他们的断言，以便更清楚地了解系统中正在发生的事情，这反过来将有助于减少错误。
结论
断言是一个了不起的工具，被太多的嵌入式开发人员忽略了。本文探讨的 7 个技巧只是如何正确使用断言的冰山一角。你可以采取的下一步是在测试台上设置并开始使用断言，并研究它们在真实嵌入式系统中的工作方式。