C# 类中项目的顺序：字段、属性、构造函数、方法

Order of items in classes: Fields, Properties, Constructors, Methods

提问by mmcdole

Is there an official C# guideline for the order of items in terms of class structure?

是否有关于类结构方面的项目顺序的官方 C# 指南？

Does it go:

去了吗：

• Public Fields
• Private Fields
• Properties
• Constructors
• Methods
  ?

• 公共领域
• 私有字段
• 特性
• 构造函数
• 方法
  ？

I'm curious if there is a hard and fast rule about the order of items? I'm kind of all over the place. I want to stick with a particular standard so I can do it everywhere.

我很好奇是否有关于项目顺序的硬性规定？我有点到处都是。我想坚持一个特定的标准，这样我就可以在任何地方做到这一点。

The real problem is my more complex properties end up looking a lot like methods and they feel out of place at the top before the constructor.

真正的问题是我更复杂的属性最终看起来很像方法，并且它们在构造函数之前的顶部感觉不合适。

Any tips/suggestions?

任何提示/建议？

采纳答案by Jonathan Wright

According to the StyleCop Rules Documentationthe ordering is as follows.

根据StyleCop 规则文档，排序如下。

Within a class, struct or interface: (SA1201 and SA1203)

在类、结构或接口中：（SA1201 和 SA1203）

• Constant Fields
• Fields
• Constructors
• Finalizers (Destructors)
• Delegates
• Events
• Enums
• Interfaces (interface implementations)
• Properties
• Indexers
• Methods
• Structs
• Classes

• 常量字段
• 字段
• 构造函数
• 终结器（析构函数）
• 代表
• 活动
• 枚举
• 接口（接口实现）
• 特性
• 索引器
• 方法
• 结构
• 班级

Within each of these groups order by access: (SA1202)

在每个组中按访问顺序排序：(SA1202)

• public
• internal
• protected internal
• protected
• private

• 民众
• 内部的
• 受保护的内部
• 受保护
• 私人的

Within each of the access groups, order by static, then non-static: (SA1204)

在每个访问组中，按静态排序，然后按非静态排序：(SA1204)

• static
• non-static

• 静止的
• 非静态

Within each of the static/non-static groups of fields, order by readonly, then non-readonly : (SA1214 and SA1215)

在每个静态/非静态字段组中，按只读排序，然后是非只读：（SA1214 和 SA1215）

• readonly
• non-readonly

• 只读
• 非只读

An unrolled list is 130 lines long, so I won't unroll it here. The methods part unrolled is:

一个展开的列表有 130 行长，所以我不会在这里展开它。展开的方法部分是：

• public static methods
• public methods
• internal static methods
• internal methods
• protected internal static methods
• protected internal methods
• protected static methods
• protected methods
• private static methods
• private methods

• 公共静态方法
• 公共方法
• 内部静态方法
• 内部方法
• 受保护的内部静态方法
• 受保护的内部方法
• 受保护的静态方法
• 受保护的方法
• 私有静态方法
• 私有方法

The documentation notes that if the prescribed order isn't suitable - say, multiple interfaces are being implemented, and the interface methods and properties should be grouped together - then use a partial class to group the related methods and properties together.

文档指出，如果规定的顺序不合适——比如，正在实现多个接口，并且接口方法和属性应该组合在一起——然后使用分部类将相关方法和属性组合在一起。

回答by Jeff Kotula

There certainly is nothing in the language that enforces it in any way. I tend to group things by visibility (public, then protected, then private) and use #regions to group related things functionally, regardless of whether it is a property, method, or whatever. Construction methods (whether actual ctors or static factory functions) are usually right at the top since they are the first thing clients need to know about.

语言中肯定没有任何东西以任何方式强制执行它。我倾向于按可见性（公共，然后是受保护，然后是私有）对事物进行分组，并使用 #regions 从功能上对相关事物进行分组，无论它是属性、方法还是其他任何东西。构造方法（无论是实际的 ctors 还是静态工厂函数）通常位于顶部，因为它们是客户需要了解的第一件事。

回答by Hamish Smith

the only coding guidelines I've seen suggested for this is to put fields at the top of the class definition.

我见过的唯一编码指南是将字段放在类定义的顶部。

i tend to put constructors next.

我倾向于将构造函数放在下一个。

my general comment would be that you should stick to one class per file and if the class is big enough that the organization of properties versus methods is a big concern, how big is the class and should you be refactoring it anyway? does it represent multiple concerns?

我的一般意见是，您应该坚持每个文件一个类，如果类足够大以至于属性与方法的组织是一个大问题，那么类有多大，您是否应该重构它？它是否代表了多个关注点？

回答by Rory Becker

The closest you're likely to find is "Design Guidelines, Managed code and the .NET Framework" (http://blogs.msdn.com/brada/articles/361363.aspx) by Brad Abrams

您可能会找到最接近的是Brad Abrams 的“设计指南、托管代码和 .NET 框架”（http://blogs.msdn.com/brada/articles/361363.aspx）

Many standards are outlined here. The relevant section is 2.8 I think.

此处概述了许多标准。我认为相关部分是2.8。

回答by Wayne

I don't know about a language or industry standard, but I tend to put things in this order with each section wrapped in a #region:

我不知道语言或行业标准，但我倾向于按以下顺序排列，每个部分都包含在 #region 中：

using Statements

使用语句

Namespace

命名空间

Class

班级

Private members

私人会员

Public properties

公共属性

Constructors

构造函数

Public methods

公共方法

Private methods

私有方法

回答by Elijah Manor

I would recommend using the coding standards from IDesignor the ones listed on Brad Abram's website. Those are the best two that I have found.

我建议使用IDesign的编码标准或Brad Abram 网站上列出的编码标准。这是我找到的最好的两个。

Brad would say...

布拉德会说...

Classes member should be alphabetized, and grouped into sections (Fields, Constructors, Properties, Events, Methods, Private interface implementations, Nested types)

类成员应按字母顺序排列，并分组为部分（字段、构造函数、属性、事件、方法、私有接口实现、嵌套类型）

回答by Ryan Lundy

Rather than grouping by visibility or by type of item (field, property, method, etc.), how about grouping by functionality?

与其按可见性或按项目类型（字段、属性、方法等）分组，不如按功能分组？

回答by blowdart

From StyleCop

来自 StyleCop

private fields, public fields, constructors, properties, public methods, private methods

私有字段、公共字段、构造函数、属性、公共方法、私有方法

As StyleCop is part of the MS build process you could view that as a de facto standard

由于 StyleCop 是 MS 构建过程的一部分，您可以将其视为事实上的标准

回答by Mitchel Sellers

As mentioned before there is nothing in the C# language that dictates the layout, I personally use regions, and I do something like this for an average class.

如前所述，C# 语言中没有任何内容来规定布局，我个人使用区域，并且我为普通班级做这样的事情。

public class myClass
{
#region Private Members

#endregion
#region Public Properties

#endregion

#region Constructors

#endregion
#region Public Methods

#endregion
}

It makes sense to me anyway

反正对我来说很有意义

回答by Wedge

I prefer to put the private fields up at the top along with the constructor(s), then put the public interface bits after that, then the private interface bits.

我更喜欢将私有字段与构造函数一起放在顶部，然后将公共接口位放在后面，然后是私有接口位。

Also, if your class definition is long enough for the ordering of items to matter much, that's probably a code smellindicating your class is too bulky and complex and you should refactor.

此外，如果您的类定义足够长，项目的排序很重要，那可能是代码异味，表明您的类过于庞大和复杂，您应该重构。

回答by Michael Damatov

Usually I try to follow the next pattern:

通常我会尝试遵循下一个模式：

• static members (have usually an other context, must be thread-safe, etc.)
• instance members

• 静态成员（通常具有其他上下文，必须是线程安全的等）
• 实例成员

Each part (static and instance) consists of the following member types:

每个部分（静态和实例）由以下成员类型组成：

• operators (are always static)
• fields (initialized before constructors)
• constructors
• destructor (is a tradition to follow the constructors)
• properties
• methods
• events

• 运算符（总是静态的）
• 字段（在构造函数之前初始化）
• 构造函数
• 析构函数（遵循构造函数的传统）
• 特性
• 方法
• 事件

Then the members are sorted by visibility (from less to more visible):

然后成员按可见性排序（从较少到较多可见）：

• private
• internal
• internal protected
• protected
• public

• 私人的
• 内部的
• 内部保护
• 受保护
• 民众

The order is not a dogma: simple classes are easier to read, however, more complex classes need context-specific grouping.

顺序不是教条：简单的类更容易阅读，但是，更复杂的类需要特定于上下文的分组。