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

Question

I'm trying to figure out what is the smartest way to name private methods and private static methods in 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.

But what is the best practice style for private and private static method naming in 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.

Answer 1

Check out the Microsoft's Naming Guidelines and Brad Abram's Style Guide

They say that all methods should be PascalCase

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

Answer 2

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

Answer 3

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

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. I have no idea if I qualify as a "hardcore pro," but I do get paid. :-)

Answer 4

One choice is to use a tool that enforces you to be consistent, such as style cop (if you use reSharper there 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.

Answer 5

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.

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.

Answer 6

The weird_underscore_naming convention is typically restricted 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