Code style for private methods in C#

Question

I just found out, that it seems a common pattern to user UpperFirstLetterPascalCase() for private methods. I for myself, find this completely inconsistent with naming rules of private instance fields and variables and I find it difficult to read/debug, too.

I would want to ask, why using a first upper letter for methods could be a better choice than a first lower (doThis())? Just out of curiosity...

Answer 1

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.

Answer 2

It isn't really better or worse. It is simply the convention.

Answer 3

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.

Answer 4

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.

Answer 5

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.

Answer 6

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!

Answer 7

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).

Answer 8

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.

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:

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) {
    ...
}