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

Answer 1

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 2

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

Why? Java standards propagating, I think.

Answer 3

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.

Answer 4

I just found Coding Standards for .Net.

Answer 5

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 6

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.