Naming Convention for Private Properties

Is there any C# naming convention for a variable used in a property?

Per Microsoft's naming conventions, the proper way would be:

private string fubar;
public string Fubar { get { return fubar; } set { fubar = value; } }

However, many people prefer to prefix the private field with an underscore to help minimize the possibility of miscapitalizing and using the field when they meant to use the property, or vice versa.

Thus, it's common to see:

private string _fubar;
public string Fubar { get { return _fubar; } set { _fubar = value; } }

The approach you take is ultimately up to you. StyleCop will enforce the former by default, whereas ReSharper will enforce the latter.

In C# 6, there is new syntax for declaring default values for properties or making read-only properties, lessening the need for properties with backing fields that don't have any special additional logic in the get and set methods. You can simply write:

public string Fubar { get; set; } = "Default Value";

or

public string Fubar { get; } = "Read-only Value";

Naming convention for private fields

You are quite right. It doesn't.

Using this is a way to ensure you are using the class member, in case of naming conflicts (say a parameter name that is identical to a field name).

For me, pascal casing public members and camel casing private members has always been enough of a convention to work well.

Naming convention for Private Properties

In this Swift Guide style, you can find a similar reference:

private var centerString: String {
  return "(\(x),\(y))"
}

In The swift Programming Language book (swift 4 beta) (link to ), you can also find these examples:

page 812:

private var privateInstance = somePrivateClass()

page 822:

private var privateVariable = 12

Excerpt From: Apple Inc. “The Swift Programming Language (Swift 4 beta).” iBooks.

I do believe that the second option is the correct way to go.

Naming convention for VB.NET private fields

I still use the _ prefix in VB for private fields, so I'll have _foo as the private field and Foo as the property. I do this for c# as well and pretty much any code I write. Generally I wouldn't get too caught up in "what is the right way to do it" because there isn't really a "right" way (altho there are some very bad ways) but rather be concerned with doing it consistently.

At the end of the day, being consistent will make your code much more readable and maintainable than using any set of "right" conventions.

Typescript private properties encapsulation conventions

Found the answer I was looking for:

https://angular.io/guide/styleguide

Properties and methods
Style 03-04
Do use lower camel case to name properties and methods.

Avoid prefixing private properties and methods with an underscore.

Why? Follows conventional thinking for properties and methods.

Why? JavaScript lacks a true private property or method.

Why? TypeScript tooling makes it easy to identify private vs. public properties and methods.

Naming conventions for private members of .NET types

Technically, underscores are a violation of .NET conventions (or at least used to be -- see comment thread), but Microsoft programmers themselves often use underscores, and many examples in the documentation use underscores. I think it's very helpful to be able to see at a glance which variables are member variables (fields) and which are local. The underscore really helps with this. It also nicely separates private member variables from local variables in intellisense.

Please see this very useful page for .NET naming conventions:

http://10rem.net/articles/net-naming-conventions-and-programming-standards---best-practices

And here's a page with Microsoft's official recommendations:

https://msdn.microsoft.com/en-us/library/ms229045%28v=vs.110%29.aspx

private members naming convention

The whole point of a standard is to promote consistency and understanding.

In this case because you have multiple languages I'd go with either "_" or "m" but make sure that you document why you've made this decision so that in 18 months time a new hire (or even you) doesn't look at the code and go "WTF?".

Naming private properties in Python

Just to sum up the discussion:

• This is mostly opinion-based because Python's "private" is by convention;
• Any solution that's readable, understandable, and consistent is good enough.

In that spirit, I'll be advocating for _x_ in my codebases (fewest additional characters). Thanks to all the commenters.

---

Related Topics