C 语言中最常见的命名约定是什么？

Question

C 语言中常用的命名约定是什么？我知道至少有两个：

1. GNU / linux / K&R with lower_case_functions
2. ？姓名 ？对于 UpperCaseFoo 函数，

我在这里只讨论 C。我们的大多数项目都是使用 C 的小型嵌入式系统。

这是我计划在下一个项目中使用的系统：

---

C 命名约定

Struct              TitleCase
Struct Members      lower_case or lowerCase

Enum                ETitleCase
Enum Members        ALL_CAPS or lowerCase

Public functions    pfx_TitleCase (pfx = two or three letter module prefix)
Private functions   TitleCase
Trivial variables   i,x,n,f etc...
Local variables     lower_case or lowerCase
Global variables    g_lowerCase or g_lower_case (searchable by g_ prefix)

Answer 1

这里最重要的是一致性。也就是说，我遵循 GTK+ 编码约定，可概括如下：

1. 所有宏和常量均大写：MAX_BUFFER_SIZE、TRACKING_ID_PREFIX。
2. 结构名称和类型定义采用驼峰式命名：GtkWidget、TrackingOrder。
3. 对结构进行操作的函数：经典 C 风格：gtk_widget_show()、tracking_order_process()。
4. 指针：这里没什么特别的：
   GtkWidget *foo，TrackingOrder *bar。
5. 全局变量：只是不要使用全局变量。他们是邪恶的。
6. 功能都有，但是
   不应该直接调用，或者有
   模糊的用途，或其他什么：一种或多种
   在开头加下划线：
   _refrobnicate_data_tables()、_destroy_cache()。

Answer 2

你知道，我喜欢保持简单，但清晰...所以这就是我在 C 中使用的内容：

• 平凡变量：i,n,c等。 .（只有一个字母。如果没有一个字母
  明确，然后将其设为局部变量）
• 局部变量：camelCase
• 全局变量：g_camelCase
• 常量变量：ALL_CAPS
• 指针变量：在前缀中添加一个p_。对于全局变量，它是 gp_var，对于局部变量，它是 p_var，对于 const 变量，它是 p_VAR。如果使用远指针，则使用 fp_ 而不是 p_。
• 结构：ModulePascalCase（模块=完整模块名称，或2-3个字母的缩写，但仍采用PascalCase。）
• 结构成员变量：camelCase
• 枚举：ModulePascalCase
• 枚举值：ALL_CAPS
• < strong>公共函数：ModulePascalCase
• 私有函数：PascalCase
• 宏：PascalCase code>

我输入了我的结构，但使用相同的名称
标签和 typedef。该标签并不适合常用。
相反，最好使用 typedef。我还在公共模块头中转发声明 typedef 以进行封装，以便我可以在定义中使用 typedef 名称。

完整 结构 示例：

typedef struct UtilsExampleStruct UtilsExampleStruct;
struct UtilsExampleStruct{
    int var;
    UtilsExampleStruct *p_link;
};

Answer 3

“结构指针”不是需要命名约定子句来覆盖它们的实体。它们只是struct WhatEver *。不要隐藏这样一个事实：巧妙且“明显”的 typedef 涉及到一个指针。它没有任何作用，打字时间更长，并且破坏了声明和访问之间的平衡。

Answer 4

首先，C 没有公共/私有/虚拟函数。这就是 C++，它有不同的约定。在 C 中，通常有：

• 全部大写的常量
• 下划线用于分隔结构或函数名称中的单词，在 C 中几乎看不到驼峰式大小写；
• 结构、typedef、联合、成员（联合和结构）和枚举值通常采用小写（根据我的经验），而不是 C++/Java/C#/etc 将第一个字母设为大写的约定，但我想这是可能的C也是。

C++ 更复杂。我在这里看到了真正的混合。类名使用驼峰式大小写或小写+下划线（根据我的经验，驼峰式大小写更常见）。结构很少使用（通常是因为库需要它们，否则您将使用类）。

Answer 5

同时使用C#、java、C、C++ 和 Objective C 进行编码，我采用了非常简单明了的命名约定来简化我的生活。

首先，它依赖于现代 IDE 的强大功能（例如 eclipse、Xcode...），可以通过悬停或 ctrl 单击来快速获取信息...
接受这一点后，我禁止使用 IDE 简单给出的任何前缀、后缀和其他标记。

然后，约定：

• 任何名称都必须是一个可读的句子，解释您所拥有的内容。就像“这是我的惯例”。
• 然后，有 4 种方法可以从句子中获得约定：
  1. THIS_IS_MY_CONVENTION 用于宏、枚举成员
  2. ThisIsMyConvention 用于文件名、对象名称（类、结构、枚举、联合...）、函数名称、方法名称、typedef
  3. this_is_my_convention 全局变量和局部变量，
     参数、结构和联合元素
  4. thisismyconvention [可选]非常局部和临时的变量（例如 for() 循环索引）

就是这样。

它给出了

class MyClass {
    enum TheEnumeration {
        FIRST_ELEMENT,
        SECOND_ELEMENT,
    }

    int class_variable;

    int MyMethod(int first_param, int second_parameter) {
        int local_variable;
        TheEnumeration local_enum;
        for(int myindex=0, myindex<class_variable, myindex++) {
             localEnum = FIRST_ELEMENT;
        }
    }
}

Answer 6

这是一个（显然）不常见的，我发现它很有用：模块名称采用驼峰式命名法，然后是下划线，然后是驼峰式命名法的函数或文件范围名称。例如：

Bluetooth_Init()
CommsHub_Update()
Serial_TxBuffer[]

Answer 7

我建议不要混合使用驼峰式大小写和下划线分隔（就像您建议的结构成员一样）。这很令人困惑。您可能会想，嘿，我有 get_length，所以我可能应该有 make_subset，然后您发现它实际上是 makeSubset。使用最少惊讶的原则，并保持一致。

我确实发现 CamelCase 对于键入名称（如结构、typedef 和枚举）很有用。不过，这就是全部了。对于其余所有内容（函数名称、结构成员名称等），我使用下划线分隔。

Answer 8

您还应该考虑单词顺序，以使自动名称完成更容易。

一个好的做法：库名称 + 模块名称 + 操作 + 主题

如果某个部分不相关，则跳过它，但至少应始终显示模块名称和操作。

示例：

• 函数名称：os_task_set_prio、list_get_size、avg_get
• 定义（这里通常没有操作部分）：OS_TASK_PRIO_MAX

Answer 9

当我在 CI 中编程时，将使用以下约定：

定义	前缀	示例
变量 - 本地 (trivial)	/	i, n, a、b... ii、nn、aa、bb... iii、nnn、aaa、bbb...
变量 -局部（描述性）	/	变量、连接...
变量 - 全局	g_	g_variable, g_connection...
变量 - 常量	c_	c_variable, c_connection...
指针	p_< /code>	p_variable 、 p_connection...
数组	a_	a_variable、a_connection。 ..
struct	s_	s_variable, s_connection...
union	u_	u_variable, < code>u_connection...
枚举	e_	e_variables、e_connection...
struct （成员） 联合（成员） 枚举（成员）	m_ m_ m_	m_variable、m_connection... m_variable、m_connection.. . m_variable、m_connection...
struct （位域）	b_	b_variable，b_connection...
函数	f_	f_variable，f_connection...
宏	o_代码>	o_variable，o_connection...

注意：

除了变量之外的每个定义都有一个字母前缀，这样它们就可以组合起来，以免被错过。

注意：

因为我的字母用完了，并且我坚持只使用小写字母前缀，所以用于宏的前缀“o_”与定义的第一个字母不匹配（macro)，但它与最后一个字母 (macro) 匹配。

如果您有任何建议，我持开放态度。

Answer 10

我对一件事感到困惑：您计划为新项目创建新的命名约定。一般来说，您应该有一个公司或团队范围内的命名约定。如果您已有的项目具有任何形式的命名约定，则不应更改新项目的约定。如果上述约定只是对您现有实践的编纂，那么您就很出色了。它与现有的事实上的标准越不同，就越难获得新标准的关注。

关于我要添加的唯一建议是，我喜欢 uint32_t 和 size_t 样式的类型末尾的 _t 。对我来说，它非常 C 式，尽管有些人可能会抱怨它只是“反向”匈牙利语。

Answer 11

可能有很多，主要是 IDE 决定了一些趋势，C++ 约定也在推动。对于 C 语言，通常有：

• UNDERSCORED_UPPER_CASE（宏定义、常量、枚举成员）
• underscored_lower_case（变量、函数）
• CamelCase（自定义类型：结构体、枚举、联合）
• uncappedCamelCase（oppa Java 风格）
• UnderScored_CamelCase（某种命名空间下的变量、函数）

匈牙利表示法全局变量很好，但不适用于类型。
即使对于简单的名称，也请至少使用两个字符。

Answer 12

我建议您阅读本文档。

摘要
本文档是 Indian Hill C 风格和编码标准论文的更新版本，由最后三位作者进行了修改。它描述了 C 程序的推荐编码标准。范围是编码风格，而不是功能组织。

Answer 13

几年过去了，这仍然是一个相关的主题。多年来我继承了大量的代码，我会说现在的风格可能与 2001 年的风格不同（而且更好）。

虽然我不太喜欢这样的编码标准，但我有一些我喜欢使用的约定，它们都有几个原因，并且与上面的一些想法相冲突：

1. 请使用长变量名。如今，我们的显示器都和电视一样宽。早在 2001 年，我们的办公桌上有一台 19 英寸 CRT 就很幸运了，但现在我们有两台 2k/27 英寸。 2001 年制定标准的人们可能已经在带有 14 英寸金鱼缸的 BBC Micros 和 IBM XT 上进行了实践。

2. 不要让类型看起来相同。例如，将枚举定义为 ThisIsAnEnum，将结构定义为 ThisIsAStruct 会使它们变得相同。我很喜欢 T_E_THIS_IS_AN_ENUM 和 T_S_THIS_IS_A_STRUCT 因为它们显然不是变量，而且它们也显然不是宏，并且您不必在其中任何一个的名称中添加“enum”。 typedef 或变量名。同样，我将 C_ 放在宏的开头，因为它们是常量，这有点误导，但它显然与其他任何东西不同。
   常量变量是一个有趣的变量，但是当编译器像变量一样处理它们时，我也这样做。编译器会告诉你是否搞砸了它们，这样就不用担心了。

3. 请说出变量有多大。这是有争议的，但任何继承旧代码的人很可能会从 8 位或 16 位系统移植到新的 32 位处理器。毕竟，这是一个嵌入式线程。然而，还有另一个好处，那就是它会告诉您一切是如何联系在一起的。例如，如果您将某些内容声明为 8 位并优化大小，那么您将在每个地址空间中压缩其中的四个 - 编译器将为您完成此操作并添加以不可见方式提取它所需的代码。然而，如果您针对速度进行优化，您将占用一个 32 位数据空间并在一个时钟周期内执行该代码。我们进入嵌入式的全部原因是为了这种级别的控制，因此这对嵌入式系统很重要（毕竟，枚举是整数）通过了解系统的变量有多大，您可以真正了解系统的很多信息。此外，我们经常看到 ARM 以其 32 位内核主导市场，但也有大量采用非 32 位低成本 PIC 或 Atmel 的设计。此外，ARM 革命可能即将成为 Risc 革命，而且 ARM 已经是 64 位了……这一切都将重演。

25 年前，代码约定在嵌入式领域并不是什么真正的东西，因为它往往是电子工程师将代码拼凑在一起的。我看到那个时代的代码，发现很多随机且不合适的“易失性”和全局变量，即使是 2024 年的免费工具也不需要这些。但如果您正在做商业工作 - 不要使用免费工具！哈哈。即使是一名研究生工程师，购买合适的工具的成本还不到一个月的工资。