C++:结构命名标准

发布于 2024-10-07 19:29:53 字数 46 浏览 3 评论 0原文

我应该如何命名结构及其变量?这包括对象内部的结构...

谢谢。

How should I name structs and their variables? This include structs inside objects...

Thanks.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

不寐倦长更 2024-10-14 19:29:53

找到你喜欢的风格并坚持下去。就这么简单。我这样做:

struct Foo
{
    int bar;
    char baz;

    Foo foo;
};

结构体和类的第一个字符大写,而内部的变量则不然。

但话又说回来,这就是我的风格,找到适合自己的风格并坚持下去。没什么可说的了。

Find a style that you like and stick to it. Its as simple as that. I do it like this:

struct Foo
{
    int bar;
    char baz;

    Foo foo;
};

Struct's and classes have their first character capitalized, variables inside don't.

But again, this is my style, find a style that suits you and stick to it. Nothing more to be said.

初心 2024-10-14 19:29:53

这是我认为非常完整的命名约定的完整列表:

  • 使用美国英语命名标识符。
  • 使用 Pascal 和 Camel 大小写命名标识符。
  • 不要使用匈牙利表示法或向标识符添加任何其他类型标识。
  • 不要为成员字段添加前缀。
  • 不要使用大小写来区分标识符。
  • 谨慎使用缩写。
  • 不要在标识符中使用下划线。
  • 根据标识符的含义而不是其类型来命名标识符。
  • 根据明确定义的模式命名名称空间。
  • 不要向类或结构名称添加后缀。
  • 使用名词或名词短语来命名类或结构。
  • 在接口前添加字母 I。
  • 对接口的默认实现使用类似的名称。
  • 属性名称后缀为 Attribute。
  • 不要将 Enum 后缀添加到枚举类型。
  • 枚举类型使用单数名称。
  • 对表示位域的枚举使用复数名称。
  • 不要使用可能被误认为数字的字母,反之亦然。
  • 将 EventHandler 添加到与事件相关的委托。
  • 向与回调方法相关的委托添加 Callback。
  • 不要向回调方法添加 Callback 或类似后缀。
  • 使用动词(动名词)来命名事件。
  • 请勿将事件后缀(或任何其他与类型相关的后缀)添加到事件名称中。
  • 使用 –ing 和 –ed 形式来表达事件前和事件后。
  • 为事件处理程序添加前缀 On。
  • 异常类后缀带有 Exception。
  • 不要向标识符添加与代码存档相关的前缀。
  • 根据包含的命名空间来命名 DLL 程序集。
  • 不要将 MR 构建块前缀添加到源文件中。
  • 使用 Pascal 大小写命名源文件。
  • 将源文件命名为主类
  • 仅使用this。建造。

这适用于 C#,但也适用于 Java/C++。如果您想标准化您的代码,我建议您查看高完整性 C++ 编码标准手册

对于外壳标识符,您应该按如下方式进行操作:

  • 类,结构(Pascal,例如:AppDomain)
  • 枚举类型(Pascal,例如:ErrorLevel)
  • 枚举值(Pascal,例如:FatalError)
  • 事件(Pascal,例如) : ValueChange)
  • 异常类 Pascal, 例如: WebException)
  • 字段 (camel, 例如: listItem)
  • Const Field Pascal, 例如: MaximumItems)
  • 只读静态字段 Pascal, 例如: RedValue)
  • 接口 (Pascal, 例如: IDisposable)
  • 方法 (Pascal,例如:ToString)
  • 命名空间(Pascal,例如:System.Drawing)
  • 参数(camel,例如:typeName)
  • 属性(Pascal,例如:BackColor)

This is complete list for Naming conventions that I consider to be very complete:

  • Use US-English for naming identifiers.
  • Use Pascal and Camel casing for naming identifiers.
  • Do not use Hungarian notation or add any other type identification to identifiers.
  • Do not prefix member fields.
  • Do not use casing to differentiate identifiers.
  • Use abbreviations with care.
  • Do not use an underscore in identifiers.
  • Name an identifier according to its meaning and not its type.
  • Name namespaces according to a well-defined pattern.
  • Do not add a suffix to a class or struct name.
  • Use a noun or a noun phrase to name a class or struct.
  • Prefix interfaces with the letter I.
  • Use similar names for the default implementation of an interface.
  • Suffix names of attributes with Attribute.
  • Do not add an Enum suffix to an enumeration type.
  • Use singular names for enumeration types.
  • Use a plural name for enumerations representing bitfields.
  • Do not use letters that can be mistaken for digits, and vice versa.
  • Add EventHandler to delegates related to events.
  • Add Callback to delegates related to callback methods.
  • Do not add a Callback or similar suffix to callback methods.
  • Use a verb (gerund) for naming an event.
  • Do not add an Event suffix (or any other type-related suffix) to the name of an event.
  • Use an –ing and –ed form to express pre-events and post-events.
  • Prefix an event handler with On.
  • Suffix exception classes with Exception.
  • Do not add code-archive related prefixes to identifiers.
  • Name DLL assemblies after their containing namespace.
  • Do not add MR building block prefixes to source files.
  • Use Pascal casing for naming source files.
  • Name the source file to the main class
  • Only use the this. construction.

This is for C# but also apply for Java/C++. If you want to standarize your code I recommend you to see the HIGH·INTEGRITY C++ CODING STANDARD MANUAL.

For casing identifiers you should do it as follow:

  • Class, Struct (Pascal, eg: AppDomain)
  • Enum type (Pascal, eg: ErrorLevel)
  • Enum values (Pascal, eg: FatalError)
  • Event (Pascal, eg: ValueChange)
  • Exception class Pascal, eg: WebException)
  • Field (camel, eg: listItem)
  • Const Field Pascal, eg: MaximumItems)
  • Read-only Static Field Pascal, eg: RedValue)
  • Interface (Pascal, eg: IDisposable)
  • Method (Pascal, eg: ToString)
  • Namespace (Pascal, eg: System.Drawing)
  • Parameter (camel, eg: typeName)
  • Property (Pascal, eg: BackColor)
找回味觉 2024-10-14 19:29:53

使您的风格与周围的人保持一致——在合理的范围内,您对结构和变量使用哪种命名方案并不重要,只要您团队中的每个人都在做一致的事情。

就我个人而言,我这样命名结构:

FunkyContainer

和这样的变量:

ratherUsefulVariable

但是你必须调整你所做的事情以适应房屋风格,否则你会破坏一致性您团队的代码。

附带说明一下,你没有“对象内部的结构”——你可以有嵌套结构,它们是结构内部的结构,但这不是同一件事。对象是结构的实例,而不是结构本身。 (显然,对象也可以是类的实例,但这与此处进行区分的目的无关。)

Harmonise your style with the people around you -- within reason, it doesn't matter which naming scheme you use for structs and variables, provided everyone on your team is doing a consistent thing.

Personally, I name structs like this:

FunkyContainer

And variables like this:

ratherUsefulVariable

But you have to adapt what you do to fit the house style, or you'll ruin the consistency of your team's code.

As a side note, you don't have "structs inside objects" -- you can have nested structs, which are structs inside structs, but that's not the same thing. An object is an instance of a struct, not the struct itself. (Objects can also be instances of classes, obviously, but that's irrelevant for the purpose of making the distinction here.)

寂寞笑我太脆弱 2024-10-14 19:29:53

我熟悉的任何命名标准都是针对平台、库等的。例如Windows SDK有标准,CRT有标准,MFC有标准。

我没见过 C++ 的标准。也许您应该看看其他人在您的特定平台上使用的命名约定。

Any naming standard I'm familiar with are for the platform, library, etc. For example, Windows SDK has a standard, the CRT has a standard, and MFC has a standard.

I've seen no standard for C++. Perhaps you should look at what naming conventions others are using on your particular platform.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文