在 C# 中命名私有和静态私有方法的最佳实践是什么？

What is the best practice for naming private and static private methods in C#?

提问by Mark Rogers

I'm trying to figure out what is the smartest way to name private methods and private static methods in C#.

我试图找出在 C# 中命名私有方法和私有静态方法的最聪明的方法是什么。

Background: I know that the best practice for private members is underscore-prefix + camelcase. You could argue this with me, but trust me I've seen enough code from hardcore pros that follow this convention, it is the skilled industry standard.

背景：我知道私人成员的最佳实践是下划线前缀 + 驼峰命名。你可以和我争论这个，但相信我，我已经看到了足够多的代码来自遵循这个约定的铁杆专业人士，这是熟练的行业标准。

I also know that pascal case is the industry standard for public methods. But I have seen a combination of test style naming (ie. method_must_return_false_occasionally ) to pascal case, camelcase, and underscore-prefix + camelcase, for private and private static methods.

我也知道 pascal case 是公共方法的行业标准。但是我已经看到了测试样式命名（即 method_must_return_false_occasionally ）到 pascal case、camelcase 和 underscore-prefix + camelcase 的组合，用于私有和私有静态方法。

But what is the best practice style for private and private static method naming in C#?

但是 C# 中私有和私有静态方法命名的最佳实践风格是什么？

If there are certain styles that are used from some private methods and not others, I can understand that, just explain.

如果某些样式是从某些私有方法而不是其他方法中使用的，我可以理解，只需解释一下。

Thanks for reading.

谢谢阅读。

采纳答案by bendewey

Check out the Microsoft's Naming Guidelinesand Brad Abram's Style Guide

查看 Microsoft 的命名指南和 Brad Abram 的样式指南

They say that all methods should be PascalCase

他们说所有的方法都应该是 PascalCase

public void DoWork() {}
private void StillDoWork() {}
private static void ContinueToDoWork() {}

回答by AnthonyWJones

I don't know about industry standards but use Pascal casing even for private methods and I make no distinction for static methods.

我不了解行业标准，但即使对于私有方法也使用 Pascal 大小写，并且我对静态方法没有区别。

回答by tvanfosson

The naming guidelinesfor .NET class library development don't distinguish between public and private usage and recommend Pascalcase for static methods.

.NET 类库开发的命名指南不区分公共和私有用法，并建议静态方法使用Pascal大小写。

EDIT: My personal practice is to use Pascal casing for methods and properties, camel casing for fields, parameters, and local variables. When referencing instance members from within the class I use this.to distinguish from class members and parameters when necessary. I have no idea if I qualify as a "hardcore pro," but I do get paid. :-)

编辑：我个人的做法是对方法和属性使用 Pascal 大小写，对字段、参数和局部变量使用驼峰大小写。当从类中引用实例成员时，我会this.在必要时用来区分类成员和参数。我不知道我是否有资格成为“铁杆专业人士”，但我确实得到了报酬。:-)

EDIT 2: Since writing this originally I've changed jobs. The coding standard we follow is different than my personal feelings and we do prefix private fields with underscores. I've also started using ReSharper and our standards (generally) follow the default rules. I find I can easily live with the underscores. I only use thiswhen absolutely required as it does not fit our code standards. Consistency trumps personal preference.

编辑 2：自从最初写这篇文章以来，我已经换了工作。我们遵循的编码标准与我的个人感受不同，我们确实用下划线作为私有字段的前缀。我也开始使用 ReSharper，我们的标准（通常）遵循默认规则。我发现我可以很容易地接受下划线。我只this在绝对需要时使用，因为它不符合我们的代码标准。一致性胜过个人偏好。

回答by Michael

One choice is to use a tool that enforces you to be consistent, such as style cop(if you use reSharperthere is a plugin for style cop on codeplex). Most of the tools seem to enforce(? suggest) the Microsoft guidelines as these get you through some tests for getting MS platform approval of your code.

一种选择是使用强制您保持一致的工具，例如style cop（如果您使用reSharper，则在codeplex上有一个 style cop 插件）。大多数工具似乎都执行（？建议）Microsoft 指南，因为它们可以让您通过一些测试，以获得 MS 平台对您的代码的批准。

回答by Michael

Each place that I have worked has always done it differently.

我工作过的每个地方的做法总是不同。

I find that as a professional developer, part of the professional is about fitting into new teams, that may have different coding conventions.

我发现作为一名专业的开发人员，专业的一部分是要适应新的团队，这可能有不同的编码约定。

Being able to switch your style and cope with the cognitive dissonance that this creates in the first few weeks, is part of the profession.

能够改变你的风格并应对这在最初几周内造成的认知失调，是这个职业的一部分。

I would start to look at the variety of open source and the like projects and you will see a wide variety of schemes.

我会开始研究各种开源项目和类似项目，你会看到各种各样的方案。

I have also seen the underscore camelCase and Pascal case debates split communites and sometimes teams - which is I guess the point of a coding scheme.

我还看到下划线驼峰式和 Pascal 案例辩论分裂了社区，有时甚至是团队——我猜这就是编码方案的重点。

So unless the project is you as sole developer in which case you are free - try find out what the rest of the team like to use and what makes it easier for the team to understand.

因此，除非该项目是您作为唯一的开发人员，在这种情况下您是免费的 - 尝试找出团队其他成员喜欢使用的内容以及使团队更容易理解的内容。

The other thing I would factor in is the complexity of the code in OO terms if this a simple project or a complex OO design with mutliple patterns or you are using some IOC then start to run a "spike" on different types of coding standard and then look at what the code physically looks like when you are using it - look nice to you and the team or does it look ugly.

我要考虑的另一件事是 OO 术语中代码的复杂性，如果这是一个简单的项目或具有多种模式的复杂 OO 设计，或者您正在使用一些 IOC 然后开始在不同类型的编码标准上运行“尖峰”然后查看代码在使用时的物理外观 - 对您和团队来说看起来不错，还是看起来很丑陋。

回答by Dmitri Nesteruk

The weird_underscore_namingconvention is typicallyrestricted to tests because it makes them more readable, and is something that is heavily encouraged by BDD. Remember that, whereas a method describes in a short way what it does (DepositMoney), tests need to describe what it is they are doing, i.e., Negative_deposits_must_be_caught

该weird_underscore_naming约定通常仅限于测试，因为它使它们更具可读性，并且 BDD 非常鼓励这样做。请记住，虽然方法以简短的方式描述了它的作用 ( DepositMoney)，但测试需要描述它们正在做什么，即，Negative_deposits_must_be_caught