10

I'm watching a video on C# about Variables. The author declares a variable inside a method and he named it like this: string MyName ="James";

my question is: which convention is recommended by .Net Framework. Is it Pascal casing as in the above example or is it camel case?

closed as primarily opinion-based by Jimmy Hoffa, Dan Pichelman, user40980, gnat, BЈовић Aug 27 '13 at 8:34

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.

  • The problem with this question, which you didn't know so it's not your fault, is that there is in fact no canonical convention for C#. There are common conventions; unfortunately more than one, but it would be quite difficult for you to get an answer here that's anything but pure opinion. Sorry, voting to close; my suggestion: Spend some time reading code in popular github and codeplex repositories to see what conventions they use as the people who write most of the popular ones are industry-experienced folks, and as canonical to what's common as you'll find. – Jimmy Hoffa Aug 26 '13 at 17:46
  • 5
    Naming conventions from MSDN - msdn.microsoft.com/en-us/library/xzf533w0(v=vs.71).aspx – EL Yusubov Aug 26 '13 at 18:01
  • 1
    @Yusubov These describe naming of the public parts of libraries, not local variables. – svick Aug 26 '13 at 21:29
25

I don't think there's something like an 'official' convention. As far as I know, the following is considered good practice by many experienced C# developers:

PascalCase for public member variables (string MyName = "James")

camelCase for local variables (string myName = "James")

_leadingUnderscore for private member variables (string _myName = "James")

With this approach, one can distinguish between local variables as well as public and private members by the case of their first letter.

As with any coding convention, this is also subject to personal preferences. Therefore, there is no definite answer. A general goal should be to keep the code as readable and comprehensible as possible.

  • 3
    +1 This is close to the style I've seen. I believe it's generally taken from the style used in MSDN's examples. Usually I see properties getting PascalCase, locals getting camelCase, and private members getting a _leadingUnderscore. – KChaloux Aug 26 '13 at 16:49
  • Do you mean Fields or Properties when you said member variables? – Kaser Aug 26 '13 at 17:03
  • Delphi developers tend to name function/method parameters by prefixing them with an 'a': (aParameter: string). I realize parameters are essentially local variables, especially when passed by value, but it is often very helpful to "see" that a var is actually passed in as a parameter. Is there any such convention in C#? – Marjan Venema Aug 26 '13 at 17:03
  • And another one: member fields. Delphians prefix them with an 'F'. I have seen C# code that declares them with an underscore: private string _SomeString. Would you say that is a convention? (Just dipping my toes in C# and wondering about this stuff). – Marjan Venema Aug 26 '13 at 17:05
  • 1
    This is inaccurate. There are published naming conventions for public members (and public classes etc.). – svick Aug 26 '13 at 21:31
7

The .Net Framework Naming Conventions (v4.5, v1.1) are agnostic about this. They do not specify a standard for naming local variables. You'll have to decide on your own convention for naming these.

I personally use camelCase, and disambiguate member variables from parameter names with this when necessary. But leading underscores (i.e. _memberVariable) are also valid.

  • 1
    This is exactly the reason of using naming conventions - using this to distinguish local variables from fields/properties. 5 additional letters every time is too much imho. – Sinatr May 13 '15 at 7:47

Not the answer you're looking for? Browse other questions tagged or ask your own question.