Pascal casing or Camel Casing for C# code?

Question

I've been arguing with my coworkers about Pascal casing (upper camel case) vs. lower CamelCasing. They are used to lower camel casing for everything from table names in SQL databases to property naming in C# code but I like Pascal casing better, lower camel casing for variables and Pascal casing for properties:

string firstName;
public string FirstName {
...
}

But they are used to this:

string _firstname;
public string firstName {
...
}

I try to keep up with their "standard" so the code looks the same but I just don't like it.

I've seen that at least the .NET framework uses this convention and that is how I try to keep my code, e.g.:

System.Console.WriteLine("string")

What do you use/prefer and why? I'm sorry if somebody else asked this question but I searched and did not find anything.

Update: I've given a method example and not a property but it's the same. As I stated in the first paragraph my colleagues use the Pascal convention for everything (variables, methods, table names, etc.)

Answer 1

I (and my team) prefer to reserve initial capitals for class names.

Why? Java standards propagating, I think.

Answer 2

Pascal casing should be used for Properties. As far as varible names go, some people use _ and some poeple use m_ and some people just use plain old camel casing. I think that as long as you ae consistant here, it shouldn't matter.

Answer 3

That example of .NET you posted was a function. The adopted "standard" for methods/functions is A capped camel-case (or Pascal, if you want to call it that).

I stick to camel case where I can. It lets you easily know the difference between a variable and a method.

Additionally, I'm a fan of sticking an underscore in front of local class variables. E.g.: _localVar.

Answer 4

I use what the Framework uses, as it's the de-facto best practice. However, so long as the code in your company is consistently using their style, then you're much better off getting used to it. If every developer has their own standard, then there's no standard at all.

Answer 5

For public interfaces you should stick with the MS .NET framework design guidelines: "Capitalization Conventions".

For non-exposed members then whatever you and your colleagues can agree on.

Answer 6

I guess you have to put up with what the coding standard says for your place of work, however much you personally dislike it. Maybe one day in the future you will be able to dictate your own coding standards.

Personally I like databases to use names of the form "fish_name", "tank_id", etc for tables and fields, whereas the code equivalent of the database model would be "fishName" and "tankID". I also dislike "_fooname" naming when "fooName" is available. But I must repeat that this is subjective, and different people will have different ideas about what is good and bad due to their prior experience and education.

Answer 7

A link to the official design guidelines might help. Specifically, read the section on Capitalization styles.

In the grand scheme of things, Pascal vs Camel doesn't matter that much and you're not likely to convince anyone to go back over an existing code base just to change the case of names.

I'm just happy as long as you're not using Hungarian.

Answer 8

Actually, there's no "standard" convention on this. There's a Microsoft edited guideline somewhere, and as with with any other naming convention guideline, surely there's another one refuting it, but here's what I've come to understand as "standard C# casing convention".

1. PerWordCaps in type names (classes, enums), constants and properties.
2. camelCase for really long local variables and protected/private variables
3. No ALL_CAPS ever (well, only in compiler defines, but not in your code)
4. It seems some of the system classes use underscored names (_name) for private variables, but I guess that comes from the original writer's background as most of them came straight from C++. Also, notice that VB.NET isn't case sensitive, so you wouldn't be able to access the protected variables if you extended the class.

Actually, FxCop will enforce a few of those rules, but (AFAIK) it ignores whatever spelling you use for local variables.

Answer 9

I like the coding conventions laid out in the Aardvark'd project spec

Answer 10

You should have a look at Microsoft's new tool, StyleCop for checking C# source code. Also keep an eye on FxCop for checking compiled .Net assemblies. FxCop focuses more on the details of what the code does, not the layout, but it does have some naming rules related to publicly visible names.

StyleCop defines a coding standard, which is now being promoted by Microsoft as an industry standard. It checks C# source code against the standard. StyleCop adheres to your PascalCase style.

Getting people onto StyleCop (or any other standard for that matter) can be hard, it's quite a hurdle, and StyleCop is quite exhaustive. But code should be to a uniform standard - and a personal standard is better than none, company standard is better than a personal one, and an industry standard is best of all.

It's a lot easier to convince people when a a project starts - team is being formed and there is no existing code to convert. And you can put tools (FxCop, StyleCop) in place to break the build if the code does not meet standards.

You should use the standard for the language and framework - SQL code should use SQL standards, and C# code should use C# standards.

Answer 11

From .NET Framework Developer's Guide Capitalization Conventions, Case-Sensitivity:

The capitalization guidelines exist solely to make identifiers easier to read and recognize. Casing cannot be used as a means of avoiding name collisions between library elements.

Do not assume that all programming languages are case-sensitive. They are not. Names cannot differ by case alone.