有趣的是，这样的重新排序会产生多大的差异。 它让我想起了 using 语句过去是如何排序的 - 首先是系统命名空间。 Visual Studio 的“组织使用”命令使用了这个顺序。 现在，using 只是按字母顺序排序，没有对系统名称空间进行特殊处理。 结果感觉更简单、更干净。
This is an old but still very relevant question, so I'll add this: What's the first thing you look for when you open up a class file that you may or may not have read before? Fields? Properties? I've realized from experience that almost invariably I go hunting for the constructors, because the most basic thing to understand is how this object is constructed.
Therefore, I've started putting constructors first in class files, and the result has been psychologically very positive. The standard recommendation of putting constructors after a bunch of other things feels dissonant.
The upcoming primary constructor feature in C# 6 provides evidence that the natural place for a constructor is at the very top of a class - in fact primary constructors are specified even before the open brace.
It's funny how much of a difference a reordering like this makes. It reminds me of how using statements used to be ordered - with the System namespaces first. Visual Studio's "Organize Usings" command used this order. Now usings are just ordered alphabetically, with no special treatment given to System namespaces. The result just feels simpler and cleaner.
public methods
public events
public properties
protected methods
protected events
protected properties
private methods
private events
private properties
private fields
public delegates
public interfaces
public classes
public structs
public records
protected delegates
protected interfaces
protected classes
protected structs
protected records
private delegates
private interfaces
private classes
private structs
private records
My preference is to order by kind and then be decreasing visibility as follows
public methods
public events
public properties
protected methods
protected events
protected properties
private methods
private events
private properties
private fields
public delegates
public interfaces
public classes
public structs
public records
protected delegates
protected interfaces
protected classes
protected structs
protected records
private delegates
private interfaces
private classes
private structs
private records
I know this violates Style Cop and if someone can give me a good reason why I should place the implementation details of a type before its interface I am willing to change. At present, I have a strong preference for putting private members last.
public class myClass
{
#region Private Members
#endregion
#region Public Properties
#endregion
#region Constructors
#endregion
#region Public Methods
#endregion
}
无论如何，这对我来说很有意义
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.
public class myClass
{
#region Private Members
#endregion
#region Public Properties
#endregion
#region Constructors
#endregion
#region Public Methods
#endregion
}
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 smell indicating your class is too bulky and complex and you should refactor.
// Some where in the fields section
private int someVariable;
// I also refrain from
// declaring variables outside of the constructor
// and some where in the properties section I do
public int SomeVariable
{
get { return someVariable; }
set { someVariable = value; }
}
I know this is old but my order is as follows:
in order of public, protected, private, internal, abstract
Constants
Static Variables
Fields
Events
Constructor(s)
Methods
Properties
Delegates
I also like to write out properties like this (instead of the shorthand approach)
// Some where in the fields section
private int someVariable;
// I also refrain from
// declaring variables outside of the constructor
// and some where in the properties section I do
public int SomeVariable
{
get { return someVariable; }
set { someVariable = value; }
}
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?
I have restructured the accepted answer, as to what I think is a better layout:
Within a class, struct or interface:
Constant Fields
Readonly Fields
Fields
Events
Properties
Indexers
Constructors
Finalizers (Destructors)
Interfaces (interface implementations)
Methods
Classes
Structs
Enums
Delegates
Within each of these groups order by access:
public
internal
protected internal
protected
private
Within each of the access groups, order by static, then non-static:
static
non-static
I also feel that nested types should be kept to a minimum. All to often I see people having nested classes, enums, delegates that would be better of being a separate instance. There hardly ever is any gain of making a type nested. Put them in separate files as well. A file with 5 classes feels cluttered to me.
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.
I would recommend using the coding standards from IDesign (webarchive) or the ones listed on Brad Abram's website. Those are the best two that I have found.
Brad would say...
Classes member should be alphabetized, and grouped into sections (Fields, Constructors, Properties, Events, Methods, Private interface implementations, Nested types)
Within a class, struct or interface: (SA1201 and 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)
public
internal
protected internal
protected
private
Within each of the access groups, order by static, then non-static: (SA1204)
static
non-static
Within each of the static/non-static groups of fields, order by readonly, then non-readonly : (SA1214 and SA1215)
readonly
non-readonly
An unrolled list is 130 lines long, so I won't unroll it here. The methods part unrolled is:
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.
发布评论
评论（16）
这是一个古老但仍然非常相关的问题，所以我将添加以下内容：当您打开以前可能读过或可能没有读过的类文件时，您首先要寻找的是什么？ 字段？ 特性？ 我从经验中意识到，我几乎总是去寻找构造函数，因为要理解的最基本的事情是这个对象是如何构造的。
因此，我开始将构造函数放在类文件中的首位，结果在心理上非常积极。 将构造函数放在一堆其他事情之后的标准建议感觉不和谐。
C# 6 中即将推出的主构造函数功能提供了证据，证明构造函数的自然位置位于类的最顶部 - 事实上，主构造函数甚至在左大括号之前就已指定。
有趣的是，这样的重新排序会产生多大的差异。 它让我想起了
using语句过去是如何排序的 - 首先是系统命名空间。 Visual Studio 的“组织使用”命令使用了这个顺序。 现在，using 只是按字母顺序排序，没有对系统名称空间进行特殊处理。 结果感觉更简单、更干净。This is an old but still very relevant question, so I'll add this: What's the first thing you look for when you open up a class file that you may or may not have read before? Fields? Properties? I've realized from experience that almost invariably I go hunting for the constructors, because the most basic thing to understand is how this object is constructed.
Therefore, I've started putting constructors first in class files, and the result has been psychologically very positive. The standard recommendation of putting constructors after a bunch of other things feels dissonant.
The upcoming primary constructor feature in C# 6 provides evidence that the natural place for a constructor is at the very top of a class - in fact primary constructors are specified even before the open brace.
It's funny how much of a difference a reordering like this makes. It reminds me of how
usingstatements used to be ordered - with the System namespaces first. Visual Studio's "Organize Usings" command used this order. Nowusings are just ordered alphabetically, with no special treatment given to System namespaces. The result just feels simpler and cleaner.与其按可见性或按项目类型（字段、属性、方法等）分组，不如按功能分组怎么样？
Rather than grouping by visibility or by type of item (field, property, method, etc.), how about grouping by functionality?
我的偏好是按类型排序，然后降低可见性，如下所示，
我知道这违反了 Style Cop，如果有人能给我一个很好的理由，为什么我应该将类型的实现细节放在其接口之前，我愿意更改。 目前，我强烈倾向于将私人成员放在最后。
注意：我不使用公共或受保护的字段。
My preference is to order by kind and then be decreasing visibility as follows
I know this violates Style Cop and if someone can give me a good reason why I should place the implementation details of a type before its interface I am willing to change. At present, I have a strong preference for putting private members last.
Note: I don't use public or protected fields.
如前所述，C# 语言中没有任何内容规定布局，我个人使用区域，并且我对普通类执行类似的操作。
无论如何，这对我来说很有意义
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.
It makes sense to me anyway
通常我尝试遵循以下模式：
每个部分（静态和实例）由以下成员类型组成：
然后按可见性对成员进行排序（从不可见到更加可见）：
该顺序不是教条：简单的类更易于阅读，但是，更复杂的类需要特定于上下文的分组。
Usually I try to follow the next pattern:
Each part (static and instance) consists of the following member types:
Then the members are sorted by visibility (from less to more visible):
The order is not a dogma: simple classes are easier to read, however, more complex classes need context-specific grouping.
从 StyleCop
私有字段、公共字段、构造函数、属性、公共方法、私有方法
由于 StyleCop 是 MS 构建过程的一部分，您可以将其视为事实上的标准
From 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
您可能找到的最接近的是“设计指南、托管代码和 .NET Framework”(http://blogs.msdn.com/brada/articles/361363.aspx）作者：Brad Abrams
此处概述了许多标准。 我认为相关部分是2.8。
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
Many standards are outlined here. The relevant section is 2.8 I think.
我更喜欢将私有字段与构造函数一起放在顶部，然后将公共接口位放在后面，然后是私有接口位。
另外，如果您的类定义足够长，使得项目的顺序非常重要，那么这可能是 代码异味表明您的类过于庞大和复杂，您应该重构。
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 smell indicating your class is too bulky and complex and you should refactor.
我让它尽可能简单（至少对我来说）
枚举
声明
构造函数
覆盖
方法
属性
事件处理程序
I keep it as simple as possible (for me at least)
Enumerations
Declarations
Constructors
Overrides
Methods
Properties
Event Handler
我知道这很旧，但我的顺序如下：
按公共，受保护，私有，内部，抽象的顺序
我也喜欢写出这样的属性（而不是简写 ）方法）
I know this is old but my order is as follows:
in order of public, protected, private, internal, abstract
I also like to write out properties like this (instead of the shorthand approach)
我见过的唯一建议的编码指南是将字段放在类定义的顶部。
我倾向于将构造函数放在其次。
我的一般意见是，您应该坚持每个文件一个类，如果该类足够大，以至于属性与方法的组织是一个大问题，那么该类有多大，您是否应该重构它？ 它是否代表了多种担忧？
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?
我已经重新构建了接受的答案，至于我认为更好的布局：
在类、结构或接口中：
在每个这些组的顺序按访问：
在每个访问组中，按静态顺序，然后是非静态：
我还认为应将嵌套类型保持在最低限度。 我经常看到人们有嵌套的类、枚举、委托，这些类、枚举、委托最好是作为一个单独的实例。 嵌套类型几乎没有任何好处。 也将它们放在单独的文件中。 包含 5 个类的文件对我来说感觉很混乱。
I have restructured the accepted answer, as to what I think is a better layout:
Within a class, struct or interface:
Within each of these groups order by access:
Within each of the access groups, order by static, then non-static:
I also feel that nested types should be kept to a minimum. All to often I see people having nested classes, enums, delegates that would be better of being a separate instance. There hardly ever is any gain of making a type nested. Put them in separate files as well. A file with 5 classes feels cluttered to me.
语言中当然没有任何内容以任何方式强制执行它。 我倾向于按可见性（公共、受保护、私有）对事物进行分组，并使用 #regions 在功能上对相关事物进行分组，无论它是属性、方法还是其他什么。 构造方法（无论是实际的构造函数还是静态工厂函数）通常位于顶部，因为它们是客户需要了解的第一件事。
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.
我建议使用 IDesign (webarchive）或 布拉德·艾布拉姆的网站。 这是我发现的最好的两个。
布拉德会说……
I would recommend using the coding standards from IDesign (webarchive) or the ones listed on Brad Abram's website. Those are the best two that I have found.
Brad would say...
我不了解语言或行业标准，但我倾向于按以下顺序放置内容，每个部分都包含在 #region 中：
using 语句
命名空间
类
私有成员
公共属性
构造函数
公共方法
私有方法
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:
using Statements
Namespace
Class
Private members
Public properties
Constructors
Public methods
Private methods
根据 StyleCop 规则文档，排序如下。
在类、结构或接口内：（SA1201 和 SA1203）
在每个组中按访问顺序排列： (SA1202)
在每个访问组内，按静态排序，然后是非静态： (SA1204)
在每个静态/非静态字段组内，按只读排序，然后non-readonly : (SA1214 和 SA1215)
展开的列表有 130 行长，所以我不会在这里展开它。 展开的方法部分是：
该文档指出，如果规定的顺序不合适 - 例如，多个接口正在实现，并且接口方法和属性应该分组在一起 - 然后使用分部类将相关方法和属性分组在一起。
According to the StyleCop Rules Documentation the ordering is as follows.
Within a class, struct or interface: (SA1201 and SA1203)
Within each of these groups order by access: (SA1202)
Within each of the access groups, order by static, then non-static: (SA1204)
Within each of the static/non-static groups of fields, order by readonly, then non-readonly : (SA1214 and SA1215)
An unrolled list is 130 lines long, so I won't unroll it here. The methods part unrolled is:
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.