c - 可重用嵌入式 C 的最佳实践？

Question

我正在为嵌入式系统(dsPIC33 平台)编写 C 代码，我正在考虑构建一个可重用的代码库以在多个项目中使用。

将库绑定(bind)到每个项目的最佳做法是什么？

显然，该库将具有一些特定于硬件(因此也特定于项目)的依赖性，因此可以合理地假设它将与每个项目一起编译(而不是以二进制形式链接)。

到目前为止，我的想法是将库保持在中心位置，但需要一个包含函数定义、宏等的特定于项目的 libraryConfig.h。这需要库在其自己的代码中包含 header ，这意味着项目源目录将需要位于包含路径中(而不仅仅是库源目录)。这搞乱了 #include "" 之间的区别和 #include <> ，不是吗？

正常情况下是这样的吗？

Answer 1

一个很好的问题，但答案并不简单。有几件事需要考虑。以下是我迄今为止的一些经验。

通用代码与项目本地副本

一个重要的决定是是使用从中央位置(贵公司的“重用库”)自动更新的“通用”库代码，还是保留项目本地副本。

这在 this SO question 中有详细讨论。 .

中央图书馆的好处是一次完成的工作可以使许多项目受益。项目本地副本的困难在于，任何错误修复和改进都不会回馈给中央库，并且中央库中的任何错误修复可能不会带入您的项目。

但是使用中央库的一个潜在困难是，如果人们以不受控制的方式修改它以适应他们的项目，并且它无意中破坏了其他项目。我亲眼看到，在充满#ifdef 并经常破坏其他项目的“通用”代码中。

要从公共(public)代码(即中央重用库)中获得好的值(value):

图书馆:

• 必须具有明确定义的需求、API 和单元测试
• 必须避免项目特定的代码；它应该是通用的
• 应该有一种机制来清晰地设置特定于项目的设置(这可以有效地视为 API 的一部分)
• 必须有正式的发布流程，包括版本号和修复，必须跟踪问题。

个别项目:

• 不应自动和盲目地获取“最新”，但应该能够获取具有指定版本号的特定“版本”。然后，项目应该可以控制是否/何时更新到较新的版本。该项目应该能够清楚地跟踪，“我们正在使用 1.2.3 版的库 xyz”。
• 应尽可能避免“ fork ”库代码。例如。避免向库代码中添加项目特定的“功能”。
• 应该跟踪对库代码的任何本地修改
• 应该将错误视为库错误，尽可能在中央库中修复。公司应该有流程在中央库中修复它们，用自己的单元测试套件测试库(可能会改进单元测试以在未来捕获错误)。然后根据需要发布中央库的新版本，并在这些项目认为合适时部署到其他项目。

如果一家公司没有这样的流程，那么一个项目应该只是制作一段代码的本地副本(比如，从以前的项目复制)，然后从那时起承担项目本地的全部责任.在那种情况下，您仍然可以从重用中获益，因为您不是从头开始重写它。

项目特定配置

如果代码需要特定于项目的配置，理想情况下应将其保留在代码中尽可能小的一部分——而不是分散在一堆源文件中。理想情况下，单个头文件。但也很可能是 .C 文件(例如，如果您需要定义一些查找表)。该库应该提供一个模板，其中的选项有很好的注释。

有关如何完成此操作的一个很好的示例，请参阅 µC/OS-II RTOS ( book ) 作者:Jean Labrosse，来自 Micrium .