仅 C 语言实现（私有）常量是否有命名约定？ [关闭]答案

【问题标题】：Is there a naming convention for C language implementation only (private) constants? [closed]仅 C 语言实现（私有）常量是否有命名约定？ [关闭]
【发布时间】：2016-01-03 00:34:39
【问题描述】：

假设我正在编写一个名为my 的库，它有一个模块myString。

myString 的公开函数和常量在 myString.h 中声明，约定如下：

typedef struct myString myString;
extern const size_t MY_STRING_MAX_LEN;
myString *my_string_new();

仅私有实现的函数和结构成员在 myString.c 中声明，约定如下：

_grow_buffer(myString *this);
char *_buffer;

我的问题：对于私有的、仅实现的常量是否有类似的约定？

例如，_CHUNK_SIZE 是我最初想要使用的。然后我读到 C 语言规范说不要在名称开头使用下划线后跟大写字母，因为这样的名称可能会在该语言的未来版本中使用。

我喜欢使用下划线开头的约定，因为它消除了很多冗长。我可以使用 MY_STRING_CHUNK_SIZE 或一些变体，但这不是 IMO 漂亮。

【问题讨论】：

不完全在您的问题范围内，但请注意许多人argue 认为全大写标识符的使用应仅限于宏。我同意那些人的看法。
@5gon12eder：实际上这是唯一被广泛接受的命名约定。
很好奇为什么有些标识以“my”开头，而另一些则以“my_”开头？IMO，它应该是另一个。

标签： c naming

【解决方案1】：

在 C 语言中，带有链接的文件范围标识符，例如函数和变量名称，通过 internal 链接对翻译单元来说是私有的。使用static 存储类说明符指示内部链接：

static char *buffer;
static void  grow_buffer(my_string *str) { /* ... */ }

这并不能解决所有问题。在大型代码库中，可能有多个标识符，例如grow_buffer 和buffer。当你想搜索buffer的定义时，被给出六种可能性是很烦人的。

因此，在静态标识符上使用一些前缀约定仍然不是一个坏主意，例如在公共函数上使用的相同前缀。如果您决定将其分类从静态更改为外部，反之亦然，这也使您不必重命名标识符。

【讨论】：

【解决方案2】：

好吧，CHUNK_SIZE_ 怎么样。这种约定在 C++ 中非常普遍，因为它与“保留”_XX 或 __XX 不冲突

【讨论】：