40

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

Improve this question
1
  • Having _underscored names like that is ugly in my opinion. Commented Feb 11 at 16:49

14 Answers 14

Reset to default
42

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.

Improve this answer
Sign up to request clarification or add additional context in comments.

3 Comments

I just wish there was a PDF/Word version of the design guidelines, I'd print it out and call it a shop-standard!
It's a big document, but not that big, and Word handles copy/paste from html pretty well. Go for it.
Summarized from the link: function parameters should use Camel case, everything else Pascal Case.
39

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.

Improve this answer

5 Comments

I disagree here. I'd try to wean the ex-Java developers on to the .NET standards, for consistency with the Framework.
Depending on the environment, changing the standard to fit the new guy is often a CLM.
Please link to the CLM to which you referred.
@Jessy - CLM: Career Limiting Maneuver. They don't come with URLs.
I voted down, sorry. I think its more important that programmers of a language are consistent across the industry and I think that should be the goal and the message.
16

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.

Improve this answer

1 Comment

FxCop is also great when working with already compiled assemblies. I learned how to do Pascal and Camel casing from using both StyleCop and FxCop
10

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.

Improve this answer

Comments

4

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

Why? Java standards propagating, I think.

Improve this answer

2 Comments

But doesn;t that force me every time I am writing code to think of whether it is an in house compoennt or a third party or framework component?
@ChrisPitman I know this is an old comment, but what bugs me more is Something(). Is that a function call or a constructor of a class?
1

I just found Coding Standards for .Net.

Improve this answer

3 Comments

Don't use URL shorteners please. Compare your version and my edit to see how to properly include links in your answer.
Thank you Meagar. Sure, I will do that from the next time
What are Lance Hunt's qualifications for writing Coding Standards for .Net?
1

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.

Improve this answer

Comments

0

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.

Improve this answer

Comments

0

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.

Improve this answer

1 Comment

There is a standard convention for this, and StyleCop enforces it.
0

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

Improve this answer

Comments

0

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.

Improve this answer

Comments

-1

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.

Improve this answer

Comments

-1

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.

Improve this answer

1 Comment

Of course, there will always be some code snobs who vote down and disagree with something perfectly reasonable :')
-5

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.

Improve this answer

Comments

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.