Pascal casing or Camel Casing for C# code?

问题:

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

回答1:

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.

回答2:

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. What's really important is that you want to be consistent within a given code base.

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

回答3:

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.

回答4:

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.

回答5:

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

Why? Java standards propagating, I think.

回答6:

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.

回答7:

I just found Coding Standards for .Net.

回答8:

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.

回答9:

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.

回答10:

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.

回答11:

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

回答12:

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.

回答13:

The day when i quit programming - its when Microsoft will make CamelCase in C# as standard. Because my grown logic has many reasons for PascalCase, unlike kid's logic, who cares only shorter names or easier to write.

And BTW: CamelCasing comes primarily from C++ STD library style, the native old language inherited from C. So Java inherited from C++. But C# - is entirely new language - clean and beauty, with new rules. Oldfags must programm on Java or C++, new generation people must programm on C# - and they should never interact.

Consider this example: 1) PascalCase: list.Capacity.ToString(); 2) CamelCase: list.capacity.toString();

In (1) we have CAMEL CASE in long TERM!!! means listCapacityToString. In (2) we have bullshit: listcapacitytoString.

Thats how i read. And why CamelCase is illogical for itselt. I could kill for PascalCase, never touch it, kids of any age.

Microsoft - forever or until they use PascalCase.

回答14:

Whichever you prefer is what matters, obviously adhering to the team's standard primarily. In private you code however you want, it doesn't affect the finished product whether you named your variable someVariable or SomeVariable.