All method names in C# start with an upper-case letter by convention. All property names do so too. Only private fields, local variables and parameters to methods start with a lower-case letter (AFAIR).
It's a convention so asking for a »why« is a little misplaced. It's probably akin to asking »Why does the Java coding convention prefer lower-case letters for everything except classes?«—answers to such questions are usually »Because someone, somewhere, once decided that it'd be a good idea to do so«. The rest then merely is history—or convention and you either follow it or you don't (in which case you make the lives of people reading your code harder).
ETA: As said in a comment already, (imho) the answer to the question »why?« usually leads to what the language designers (or the people coming up with the convention) considered to be important aspects to be covered by the convention. In Java it's clearly a case of visually distinguishing classes (PascalCase), variables/fields (camelCase) and properties (get~()/set~()). For .NET there obviously was a need of immediately telling classes and interfaces apart (something I consider pretty nice to have too) and visually distinguishing property (PascalCase) and field (camelCase) access.
Usually in such scenarios all things not initially considered important for the convention fall short in obviousness.
Such is the naming convention for .NET, and that is the convention that all standard .NET libraries follow. There's nothing that requires you to follow this convention in your own code, but it's usually best to follow the standards of the language you're working in. Personally, I prefer lowerCamelCase to UpperCamelCase, but I still use the recommended .NET style when writing in C#.
Private member variables are commonly indicated with a leading underscore and lower-case first letter, e.g. _privateMember. Private methods follow the same conventions as public methods.
I do think that you should choose you naming conventions according with your own likes/dislikes, no matter how other people do it (unless of course the guy paying the check says otherwise).
Important stuff is: once you choose a convention, stick with it!
我能想到的一个区别是它区分本地委托变量和方法，尽管这可能不是意图。在现代 IDE 中，通常很容易找出调用是公共调用还是私有调用（无论如何）。我对属性、字段和变量的命名约定的看法是，它们允许区分同一“属性”的不同形式，如下所示：
public class MyClass
{
private int _property;
public int Property
{
get { return _property; }
}
public MyClass(int property)
{
_property = property;
}
}
One difference I could think of is that it distinguishes between local delegate variables and methods, though this is probably not the intention. With modern IDEs, it's generally pretty easy to find out if the call is public or private, in any case. My take on the naming conventions for properties, fields and variables is that they allow distinguishing different forms of the same 'property' like so:
public class MyClass
{
private int _property;
public int Property
{
get { return _property; }
}
public MyClass(int property)
{
_property = property;
}
}
With methods you don't have the same ambiguity where you'd like to use the same name for different forms of the same concept (other than overloads, which don't require different casings to distinguish them).
I'd just like to point out that while yes, PascalCase is the convention in .NET for private as well as public methods, considering we're talking about private methods here, I see no harm in choosing what looks better to you. I mean, you do have a point that there seems to be merit in differentiating between private a public methods. As long as what you're exposing to the client (if you're developing a library) is consistent with the convention, you're golden. Just work out with any team members how you're going to do things internally.
The main thing you gain from this convention is the ability to easily distinguish method calls from member variable and parameter access.
As others have mentioned, it isn't necessarily better - it's just the trade-off that .NET developers have chosen and stuck with: making it easier to tell what you're accessing rather than making it easier to tell the accessibility level of the thing you're accessing.
Properties make this especially valuable, which may explain why it took root in the .NET world. Being able to tell the difference between a property access and a member variable access can be critical. Property accessors may be calculating or validating values, and calling the related member variable by mistake (or vice-versa) creates subtle bugs.
Test test = new Test();
test.MyEvent += myEventHandler;
private void myEventHandler(object sender, EventArgs e) {
...
}
I tend to look at the entire method signature when I read code. If I don't see an access modifier (public, protected, internal, protected internal) then I can assume it's private (although I try to be explicit about access modifiers).
You are free to adopt your own convention though - particularly for private methods.
public class Test {
public event EventHandler MyEvent;
}
If I create a private method for handling MyEvent and add the handler using C#'s implicit method group conversion syntax a lowercase method name could be confused with a field or variable:
Test test = new Test();
test.MyEvent += myEventHandler;
private void myEventHandler(object sender, EventArgs e) {
...
}
发布评论
评论（8）
按照惯例，C# 中的所有方法名称均以大写字母开头。所有属性名称也都是如此。只有私有字段、局部变量和方法参数以小写字母 (AFAIR) 开头。
这是一个惯例，所以询问“为什么”有点不合时宜。这可能类似于问“为什么 Java 编码约定更喜欢除类之外的所有内容都使用小写字母？”——此类问题的答案通常是“因为某个地方的某人曾经决定这样做是个好主意” 。剩下的就只是历史——或者惯例，你要么遵循它，要么不遵循（在这种情况下，你会让阅读你的代码的人的生活变得更加困难）。
预计到达时间：正如评论中所说，（恕我直言）“为什么？”这个问题的答案通常会导致语言设计者（或提出约定的人）认为重要的方面纳入公约范围。在 Java 中，这显然是视觉上区分类 (PascalCase)、变量/字段 (camelCase) 和属性 (get~()/set~()) 的情况。对于.NET，显然需要立即区分类和接口（我认为这也很好）以及在视觉上区分属性（PascalCase）和字段（camelCase）访问。
通常在这种情况下，所有最初被认为对公约不重要的事情都不够明显。
All method names in C# start with an upper-case letter by convention. All property names do so too. Only private fields, local variables and parameters to methods start with a lower-case letter (AFAIR).
It's a convention so asking for a »why« is a little misplaced. It's probably akin to asking »Why does the Java coding convention prefer lower-case letters for everything except classes?«—answers to such questions are usually »Because someone, somewhere, once decided that it'd be a good idea to do so«. The rest then merely is history—or convention and you either follow it or you don't (in which case you make the lives of people reading your code harder).
ETA: As said in a comment already, (imho) the answer to the question »why?« usually leads to what the language designers (or the people coming up with the convention) considered to be important aspects to be covered by the convention. In Java it's clearly a case of visually distinguishing classes (PascalCase), variables/fields (camelCase) and properties (get~()/set~()). For .NET there obviously was a need of immediately telling classes and interfaces apart (something I consider pretty nice to have too) and visually distinguishing property (PascalCase) and field (camelCase) access.
Usually in such scenarios all things not initially considered important for the convention fall short in obviousness.
这并不是真正更好或更坏。这只是惯例。
It isn't really better or worse. It is simply the convention.
这就是 .NET 的命名约定，也是所有标准 .NET 库遵循的约定。没有什么要求您在自己的代码中遵循此约定，但通常最好遵循您所使用的语言的标准。就我个人而言，我更喜欢小驼峰命名法而不是大驼峰命名法，但在编写时我仍然使用推荐的 .NET 风格在 C# 中。
私有成员变量通常用前导下划线和小写首字母表示，例如
_privateMember。私有方法遵循与公共方法相同的约定。Such is the naming convention for .NET, and that is the convention that all standard .NET libraries follow. There's nothing that requires you to follow this convention in your own code, but it's usually best to follow the standards of the language you're working in. Personally, I prefer lowerCamelCase to UpperCamelCase, but I still use the recommended .NET style when writing in C#.
Private member variables are commonly indicated with a leading underscore and lower-case first letter, e.g.
_privateMember. Private methods follow the same conventions as public methods.我确实认为你应该根据自己的喜欢/不喜欢来选择命名约定，不管其他人怎么做（当然除非付钱的人另有说明）。
重要的是：一旦选择了约定，就坚持下去！
I do think that you should choose you naming conventions according with your own likes/dislikes, no matter how other people do it (unless of course the guy paying the check says otherwise).
Important stuff is: once you choose a convention, stick with it!
我能想到的一个区别是它区分本地委托变量和方法，尽管这可能不是意图。在现代 IDE 中，通常很容易找出调用是公共调用还是私有调用（无论如何）。我对属性、字段和变量的命名约定的看法是，它们允许区分同一“属性”的不同形式，如下所示：
使用方法，您不会有相同的歧义，您希望对不同的名称使用相同的名称。相同概念的形式（重载除外，重载不需要不同的大小写来区分它们）。
One difference I could think of is that it distinguishes between local delegate variables and methods, though this is probably not the intention. With modern IDEs, it's generally pretty easy to find out if the call is public or private, in any case. My take on the naming conventions for properties, fields and variables is that they allow distinguishing different forms of the same 'property' like so:
With methods you don't have the same ambiguity where you'd like to use the same name for different forms of the same concept (other than overloads, which don't require different casings to distinguish them).
我只想指出，虽然 PascalCase 是 .NET 中私有和公共方法的约定，但考虑到我们在这里讨论的是私有方法，我认为选择它并没有什么坏处什么对你来说看起来更好。我的意思是，您确实有这样的观点：区分私有方法和公共方法似乎是有优点的。只要您向客户端公开的内容（如果您正在开发一个库）符合约定，那么您就是黄金。只需与任何团队成员一起确定如何在内部做事即可。
I'd just like to point out that while yes, PascalCase is the convention in .NET for private as well as public methods, considering we're talking about private methods here, I see no harm in choosing what looks better to you. I mean, you do have a point that there seems to be merit in differentiating between private a public methods. As long as what you're exposing to the client (if you're developing a library) is consistent with the convention, you're golden. Just work out with any team members how you're going to do things internally.
从这个约定中您获得的主要好处是能够轻松地区分方法调用与成员变量和参数访问。
正如其他人所提到的，它不一定更好 - 这只是 .NET 开发人员选择并坚持的权衡：让您更容易知道您正在访问什么，而不是让事情变得更容易告诉您正在访问的内容的可访问级别。
属性使其特别有价值，这可以解释为什么它扎根于 .NET 世界。能够区分属性访问和成员变量访问之间的区别至关重要。属性访问器可能正在计算或验证值，并且错误地调用相关的成员变量（反之亦然）会产生微妙的错误。
The main thing you gain from this convention is the ability to easily distinguish method calls from member variable and parameter access.
As others have mentioned, it isn't necessarily better - it's just the trade-off that .NET developers have chosen and stuck with: making it easier to tell what you're accessing rather than making it easier to tell the accessibility level of the thing you're accessing.
Properties make this especially valuable, which may explain why it took root in the .NET world. Being able to tell the difference between a property access and a member variable access can be critical. Property accessors may be calculating or validating values, and calling the related member variable by mistake (or vice-versa) creates subtle bugs.
当我阅读代码时，我倾向于查看整个方法签名。如果我没有看到访问修饰符（
public、protected、internal、protected inside），那么我可以假设它是私有的（尽管我尝试明确访问修饰符）。不过，您可以自由地采用自己的约定 - 特别是对于
private方法。在一种情况下，我能想到该约定很有用：当使用 C# 时隐式方法组转换语法。考虑此类，
Test：如果我创建一个私有方法来处理
MyEvent并使用 C# 的隐式方法组转换语法添加处理程序，则小写方法名称可能会与字段混淆或变量：I tend to look at the entire method signature when I read code. If I don't see an access modifier (
public,protected,internal,protected internal) then I can assume it'sprivate(although I try to be explicit about access modifiers).You are free to adopt your own convention though - particularly for
privatemethods.There's one case I can think of where the convention is useful: when using C#'s implicit method group conversion syntax. Consider this class,
Test:If I create a private method for handling
MyEventand add the handler using C#'s implicit method group conversion syntax a lowercase method name could be confused with a field or variable: