C中最常见的命名约定是什么？
C中常用的命名约定是什么？ 我知道至less有两个：
- GNU / linux / K＆R与lower_case_functions
- ？ 名称 ？ 与UpperCaseFoo函数
我只在这里谈论C。 我们的大部分项目都是使用C语言的小型embedded式系统。
下面是我计划在下一个项目中使用的一个：
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) 这里最重要的是一致性。 也就是说，我遵循GTK +编码约定，可以概括如下：
- 所有的macros和常量大写：
MAX_BUFFER_SIZE，TRACKING_ID_PREFIX。 - 结构名称和typedef在camelcase中：
GtkWidget，TrackingOrder。 - 对结构进行操作的函数：经典C风格：
gtk_widget_show()，tracking_order_process()。 - 指针：这里没什么特别的：
GtkWidget *foo，TrackingOrder *bar。 - 全局variables：只是不要使用全局variables。 他们是邪恶的。
- 在那里的函数，但不应该直接调用，或者有晦涩的用法，或者其他的：在开头的一个或多个下划线：
_refrobnicate_data_tables()，_destroy_cache()。
“结构指针”不是需要命名约定条款来覆盖它们的实体。 他们只是struct WhatEver * 。 不要隐藏有一个指针与一个聪明的和“明显的”typedef有关的事实。 它没有任何用处，打字时间更长，破坏了声明和访问之间的平衡。
那么首先C没有公共/私人/虚拟function。 这是C ++，它有不同的约定。 在C通常你有：
- ALL_CAPS中的常量
- 在结构体或函数名中用下划线来分隔单词，在C中几乎看不到骆驼的情况;
- 结构，types定义，工会，成员（工会和结构）和枚举值通常是小写（根据我的经验）而不是C ++ / Java / C＃/等约定的首字母大写，但我想这是可能的C也是。
C ++更复杂。 我在这里看到了一个真正的混合。 骆驼案例的类名或小写+下划线（骆驼案件是在我的经验更常见）。 结构很less使用（通常是因为一个库需要它们，否则你会使用类）。
在C＃，Java，C，C ++和Objective C中同时进行编码，我采用了一个非常简单明了的命名约定来简化我的生活。
首先，它依靠现代IDE（如eclipse，Xcode …）的强大function，通过鼠标hover或Ctrl点击来获得快速的信息…接受这一点，我禁止使用任何前缀，后缀以及IDE简单给出的其他标记。
那么，公约：
- 任何名字必须是一个可读的句子，解释你有什么。 像“这是我的约定”。
- 然后，从句子中得到一个约定的4种方法：
- 对于macros，枚举成员是THIS_IS_MY_CONVENTION
- ThisIsMyConvention为文件名称，对象名称（类，结构，枚举，联合…），函数名称，方法名称，typedef
- this_is_my_convention全局和局部variables，
参数，结构和联合元素 - thisismyconvention [可选]非常本地和临时variables（如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; } } }
我会build议不要混合骆驼案件和下划线分离（就像你build议的结构成员）。 这很混乱。 你会想，嘿，我有get_length所以我应该可能有make_subset ，然后你发现它实际上是makeSubset 。 使用最小的原则，并保持一致。
我发现CamelCase有用于键入名称，如结构，typedefs和枚举。 这是所有，但。 对于所有其余的（函数名称，结构成员名称等），我使用underscore_separation。
这是一个（显然）不常见的，我发现它很有用：CamelCase中的模块名，然后是一个下划线，然后在CamelCase中的函数或文件范围名称。 举个例子：
Bluetooth_Init() CommsHub_Update() Serial_TxBuffer[]
我很困惑的一件事：你打算为一个新的项目创build一个新的命名约定。 一般来说，您应该有一个公司或团队的命名约定。 如果您已经有具有任何forms的命名约定的项目，则不应更改新项目的约定。 如果上述公约只是对现有惯例的编纂，那么你就是金。 与现有的事实标准不同的是，在新标准中获得更多的信任将会越来越困难。
关于唯一的build议，我会补充说，我喜欢uint32_t和size_t风格的types的结尾。 虽然有些人可能会抱怨说这只是“反向”的匈牙利语，但对我来说却是非常不好的。
您还应该考虑单词的顺序，以使自动完成名称更容易。
一个好的做法是：库名+模块名+动作+主题
如果零件不相关，只需跳过它，但至less应该显示一个模块名称和一个动作。
例子：
- 函数名称：
os_task_set_prio，list_get_size，avg_get - 定义（这里通常没有动作部分）：
OS_TASK_PRIO_MAX
可能有很多，主要是IDE支配一些趋势，而C ++的惯例也在推动。 对于C一般：
- UNDERSCORED_UPPER_CASE（macros定义，常量，枚举成员）
- underscored_lower_case（variables，函数）
- CamelCase（自定义types：结构，枚举，联合）
- uncappedCamelCase（oppa Java风格）
- UnderScored_CamelCase（variables，types下的函数名称空间）
匈牙利符号的全局是好的，但不是types。 甚至对于不起眼的名字，请使用至less两个字符。
