在C中命名类型时使用的样式

是的,posix保留名称结尾 _t 如果您包含任何POSIX头文件,那么建议您在理论上远离这些头文件。我在一个项目上工作,在过去的二十年左右的时间里,有两三次这样的名字。您可以通过使用公司前缀(例如,您公司的TLA和下划线)或使用混合大小写名称(以及 艾特 后缀);我看到的所有碰撞都是短的,都是小写的。( dec_t , loc_t ,……)

除提供的系统(和系统保留)外 艾特 后缀,没有具体广泛使用的约定。其中一个混合大小写系统(camelcase或initialcaps)工作得很好。系统前缀也能很好地工作——更好的库往往会小心处理这些前缀。

如果你决定用小写字母和 艾特 后缀,请确保您使用足够长的名称,并仔细检查POSIX标准、您所使用的主要平台以及您认为可以使用的任何平台,以避免不必要的冲突。最糟糕的问题是当你说出某个名字 example_t 然后发现在一些新平台上存在冲突。然后你必须考虑让客户改变他们的代码,而他们总是不愿意这样做。最好预先避免这个问题。

这个 Indian Hill style guidelines 有一些建议:

毫无疑问,单个项目 他们自己的命名约定。那里 不过是一些一般规则。

• 带有前导和尾随下划线的名称保留给系统 不得用于 任何用户创建的名称。大多数系统 将它们用于用户 不必知道。如果你必须 有你自己的私人标识符, 以一两个字母开头 确定他们要去的包裹 属于。

• #define 常量应全部大写。

• 枚举常量大写或全部大写

• 函数、typedef和变量名,以及结构、联合和 枚举标记名称应位于下方 案例。

• 许多宏“函数”都是大写的。一些宏(如getchar和 putchar)是小写,因为它们 也可以作为函数存在。 只有小写宏名称 如果宏的行为类似于 函数调用,也就是说,它们计算 他们的参数只有一次 不为命名参数赋值。 有时候写一个 类似于函数的宏 即使争论是 只计算一次。

• 避免使用只有大小写不同的名称,如foo和foo。同样地, 避开foo bar和foo_bar。这个 潜在的困惑是 相当可观。

• 同样,避免使用彼此相似的名称。在许多终端和 打印机“l”、“1”和“i”看起来很像 类似的。名为“l”的变量是 特别糟糕,因为它看起来如此 就像常数“1”。

一般来说,全局名称(包括 枚举)应具有公共前缀 确定他们的模块 属于。全球可选择 按全局结构分组。 typedeffed名称通常有“t” 附加到他们的名字。

避免使用可能与之冲突的名称 各种标准库名称。一些 系统将包含更多的库代码 比你想要的要多。此外,您的计划可能 总有一天会被延长。

C只准备金 一些 A的用法 _t 后缀。据我所知,这只是以 艾特 加上任何开始的标识符 int 或 uint (7.22.8)。然而,posix可能会保留更多。

在C中这是一个普遍的问题,因为您有非常平坦的名称空间,而且没有银弹。 如果您熟悉capcase名称,并且它们对您很有用,那么您应该继续使用它们。 否则,您将不得不评估当前项目的目标,并查看哪个解决方案最能满足这些目标。

capcase通常用于c中的类型。

例如,如果您查看gnome生态系统中的项目(gtk+、gdk、glib、gobject、clutter等),您将看到类似的类型 GtkButton 或 ClutterStageWindow . 他们 只有 对数据类型使用capcase;函数名和变量都是小写,带有下划线分隔符-例如 clutter_actor_get_geometry() .

类型命名方案类似于缩排惯例——它们引发宗教战争,人们为他们的首选方法断言某种道德优越性。当然,最好在现有代码或相关项目中遵循这种风格(例如,在过去几年中,对于我、GNOME)。

然而,如果你从头开始,没有模板,就没有硬性和快速的规则。如果你对高效编码感兴趣,并且在合理的时间离开工作,这样你就可以回家喝啤酒或其他什么,你当然应该为你的项目选择一种风格并坚持下去,但是你选择哪种风格并不重要。

另一种可行的解决方案是对所有类型名和宏名使用大写。全局变量可以是capcase(camelback)和所有局部变量小写。

这种技术有助于提高可读性,并利用语言语法减少变量名中污染字符的数量;例如,gvar、kvar、type_t等。例如,数据类型不能与任何其他类型在语法上混淆。

全局变量通过至少有一个大写字母很容易与局部变量区分开来。

我同意在所有令牌名称中应避免使用前缀或后缀下划线。

让我们看看下面的例子。

很明显,InvertedCount是全局的,因为它的情况。同样清楚的是,Int32u和Ret_Err是由于其Sytax而成为类型。它还清楚地表明invert_val()是一个宏,因为它在右边,并且没有强制转换,所以它不能是数据类型。

但有一点是肯定的。无论使用哪种方法,它都应该与组织的编码标准保持一致。对我来说,最少的杂乱,更好。

当然,风格是另一个问题。

#define  INVERT_VAL(x)   (~x)
#define  CALIBRATED_VAL  100u

INT32U  InvertedCount;

typedef  enum {
    ERR_NONE = 0,
    ...
} RET_ERR;

RET_ERR  my_func (void) 
{
    INT32U  val;
    INT32U  check_sum;


    val           = CALIBRATED_VAL;   // --> Lower case local variable.
    check_sum     = INVERT_VAL(val);  // --> Clear use of macris.

    InvertedCount = checksum;         // --> Upper case global variable.  
                                      //     Looks different no g prefix required.

    ... 

    return (ERR_NONE); 
}

关于这个主题有很多想法和观点,但是没有一个通用的命名类型标准。最重要的是保持一致。在没有编码标准的情况下,在维护代码时,要抵制使用另一种命名约定的冲动。引入一个新的命名约定,即使它是完美的,也会增加不必要的复杂性。

这实际上是一个很好的话题,在采访人时提出。我从来没有遇到过一个对此没有意见的好程序员。答案中没有意见或激情表明这个人不是一个有经验的程序员。