C中最常见的命名约定是什么?

C中常用的命名约定是什么? 我知道至less有两个:

  1. GNU / linux / K&R与lower_case_functions
  2. ? 名称 ? 与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 +编码约定,可以概括如下:

  1. 所有的macros和常量大写: MAX_BUFFER_SIZETRACKING_ID_PREFIX
  2. 结构名称和typedef在camelcase中: GtkWidgetTrackingOrder
  3. 对结构进行操作的函数:经典C风格: gtk_widget_show()tracking_order_process()
  4. 指针:这里没什么特别的: GtkWidget *fooTrackingOrder *bar
  5. 全局variables:只是不要使用全局variables。 他们是邪恶的。
  6. 在那里的函数,但不应该直接调用,或者有晦涩的用法,或者其他的:在开头的一个或多个下划线: _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种方法:
    1. 对于macros,枚举成员是THIS_IS_MY_CONVENTION
    2. ThisIsMyConvention为文件名称,对象名称(类,结构,枚举,联合…),函数名称,方法名称,typedef
    3. this_is_my_convention全局和局部variables,
      参数,结构和联合元素
    4. 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_priolist_get_sizeavg_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两个字符。