我们正在开发一个用 C 编写的游戏引擎，目前我们正在使用以下命名约定。
ABClass object;
ABClassMethod(object, args)
AB作为我们的前缀。
我们的 API，即使在对象上工作，也没有继承、多态或任何东西。我们所拥有的只是数据类型和处理它们的方法。
我们的常量命名相似：AB_ConstantName 和预处理器宏命名相似AB_API_BEGIN。我们不使用宏之类的函数。
我想知道这如何适合作为 C API。此外，您可能会注意到整个 API 封装在 lua 中，您可以使用来自 C 或 lua 的 API。大多数情况下，引擎将从 lua 中使用。
【问题讨论】：
标签： c naming-conventions
无论您将推出何种 API，为了您的用户（以及您的）精神健全，请确保它在整个代码中保持一致。
对我来说，一致性包括三件事：
命名。应规范下划线的大小写和使用。例如： ABClass() 是一个“公共”符号，而 AB_Class() 不是（在某种意义上它可能对其他模块可见（无论出于何种原因），但它保留供内部使用。 如果你有“ABClass()”，你就不应该有“abOtherClass()”或“AbYet_anotherClass()”
名词和动词。如果某事物被称为“点”，则它必须始终为“点”而不是“pnt”或“p”或类似名称。
例如，标准 C 库同时具有 putc() 和 putchar()（是的，它们是不同的，但名称并不能说明是哪一个写入标准输出）。
动词也应该保持一致：避免同时使用“CreateNewPoint()”、“BuildCircle()”和“NewSquareMake()”！
参数位置。如果一组相关函数采用相似的参数（例如字符串或文件），请确保它们具有相同的位置。同样，C 标准库在 fwrite() 和 fprintf() 方面做得很差：一个将文件作为最后一个参数，另一个作为第一个参数。
其余的很大程度上取决于您的口味以及您可能遇到的任何其他限制。
例如，您提到您正在使用 Lua：如果程序员必须同时使用这两种 API，那么遵循与 Lua 类似的约定可能是一个加分项。
【讨论】：
这似乎足够标准。 OpenGL 使用gl 前缀做到了这一点，所以你不可能离得那么远。 :)
【讨论】：
有很多 C API。如果你有足够的创造力来发明一个新的，没有“多数”可以责怪你。另一方面，无论你走哪条路，都会有足够多的其他标准狂热者来生你的气。
【讨论】：