Interfaces: PascalCase with I prefix (IDisposable)
Methods: PascalCase (ToUpper)
Properties: PascalCase (Length)
Events: PascalCase (Click)
Namespaces: PascalCase (System.Collections; unusual to have two words in one part though)
Non-constant variables including parameters: camelCased (keySelector)
Constants: PascalCase (Int32.MaxValue)
Enums: PascalCase, singular for non-flags and plural for flags (HttpStatusCode, BindingFlags)
Attributes: PascalCase with "Attribute" suffix (ThreadStaticAttribute)
Private names are up to you, but I tend to follow the same conventions as for everything else. Hungarian notation (in the style of Win32) is discouraged, although many places use "m_" or "_" as a prefix for instance variables.
The .NET standard from Microsoft is to use Pascal Case for namespaces, public and protected members (basically anything visible to other classes). For private members and local variables, there's a much wider berth to just do whatever you and your team are most comfortable with.
I'd have a look at the slim book called "Elements of C# Style" by Baldwin, Gray, & Misfeldt. The blue book covers naming conventions, and many other aspects of creating consistent, clean, readable code.
发布评论
评论（6）
Microsoft 有一套出色的关于类库设计的指南，包括< href="http://msdn.microsoft.com/en-us/library/ms229002.aspx" rel="noreferrer">有关命名的部分。简而言之（括号中的示例）：
WebRequest)IDisposable)ToUpper) >)Length)Click)System.Collections；两个单词合而为一的情况并不常见 包括参数在内keySelector)Int32.MaxValue)HttpStatusCode,BindingFlags)ThreadStaticAttribute)私有名称由您决定，但我倾向于遵循相同的名称与其他一切一样的约定。尽管许多地方使用“m_”或“_”作为实例变量的前缀，但不鼓励使用匈牙利表示法（Win32 风格）。
Microsoft has an excellent set of guidelines on class library design, including a section on naming. In short (examples in parentheses):
WebRequest)IDisposable)ToUpper)Length)Click)System.Collections; unusual to have two words in one part though)keySelector)Int32.MaxValue)HttpStatusCode,BindingFlags)ThreadStaticAttribute)Private names are up to you, but I tend to follow the same conventions as for everything else. Hungarian notation (in the style of Win32) is discouraged, although many places use "m_" or "_" as a prefix for instance variables.
Resharper 的指南建议
Resharper's guidelines suggest
Microsoft 的 .NET 标准是使用 Pascal Case< /a> 用于名称空间、公共和受保护成员（基本上是其他类可见的任何内容）。对于私有成员和局部变量，有更广泛的空间可以做您和您的团队最舒服的事情。
The .NET standard from Microsoft is to use Pascal Case for namespaces, public and protected members (basically anything visible to other classes). For private members and local variables, there's a much wider berth to just do whatever you and your team are most comfortable with.
不要低估尽可能严格遵循您正在使用的平台的命名约定的价值。
查看 .NET Framework 的参考材料，了解如何“适应”的示例 (http://msdn.microsoft.com/en-us/library/ms229335.aspx）。
Jon Skeet 为您提供了 Microsoft 一篇精彩文章的链接：http:// msdn.microsoft.com/en-us/library/ms229042.aspx
您还可以使用独立的 Microsoft FxCop（或代码分析，如果您有团队版）http://www.microsoft.com/downloads/details.aspx?FamilyID= 9aeaa970-f281-4fb0-aba1-d59d7ed09772&DisplayLang=en 检查是否遵循命名约定。它具有针对 Microsoft 约定的内置规则，这是您应该使用它们的另一个原因！
Don't underestimate the value of following the naming conventions of the platform you are working on as closely as possible.
Look at the reference material for the .NET Framework for examples of how to "fit in" (http://msdn.microsoft.com/en-us/library/ms229335.aspx).
Jon Skeet has given you a link to a good writeup by Microsoft: http://msdn.microsoft.com/en-us/library/ms229042.aspx
You can also use the standalone Microsoft FxCop (or Code Analysis if you have the Team Edition) http://www.microsoft.com/downloads/details.aspx?FamilyID=9aeaa970-f281-4fb0-aba1-d59d7ed09772&DisplayLang=en to check that the naming conventions have been followed. It has built-in rules for the Microsoft conventions, which is another reason you should be using them!
Juval Lowy 在 Programming .NET Components 中对此进行了尝试，请参阅此SO 链接。
Juval Lowy took a stab at this is in Programming .NET Components, see this SO link too.
我想看一本名为“C# 风格的元素”的薄书” 作者：鲍德温、格雷和米斯费尔特。蓝皮书涵盖了命名约定以及创建一致、干净、可读代码的许多其他方面。
I'd have a look at the slim book called "Elements of C# Style" by Baldwin, Gray, & Misfeldt. The blue book covers naming conventions, and many other aspects of creating consistent, clean, readable code.