Question

I’m taking a C# class right now and I’m trying to find out the best way of doing things. I come from a Java background and so I’m only familiar with Java best-practices; I’m a C# novice!

In Java if I have a private property, I do this;

private String name;

public void setName(String name) {
   this.name = name;
}

public String getName() {
   return this.name;
}

In C#, I see that there are many ways of doing this.

I can do it like Java:

private string name;

public void setName(string name) {
   this.name = name;
}

public string getName() {
   return this.name;
}

Or I can do it this way:

private string name;

public string Name {
   get { return name; }
   set { name = value; }
}

Or:

public string Name { get; set; }

Which one should I use, and what are the caveats or subtleties involved with each approach? When creating classes, I am following general best-practices that I know from Java (especially reading Effective Java). So for example, I am favoring immutability (providing setters only when necessary). I’m just curious to see how these practices fit in with the various ways of providing setters and getters in C#; essentially, how would I translate best-practices from the Java world into C#?

EDIT

I was posting this as a comment to Jon Skeet’s answer but then it got long:

What about a non-trivial property (i.e., with significant processing and validation perhaps)? Could I still expose it via a public property but with the logic encapsulated in get and set? Why would/should I do this over having dedicated setter and getter methods (with associated processing and validation logic).

Answer 1

Pre-C# 6

I’d use the last of these, for a trivial property. Note that I’d call this a public property as both the getters and setters are public.

Immutability is a bit of a pain with automatically implemented properties – you can’t write an auto-property which only has a getter; the closest you can come is:

public string Foo { get; private set; }

which isn’t really immutable… just immutable outside your class. So you may wish to use a real read-only property instead:

private readonly string foo;
public string Foo { get { return foo; } }

You definitely don’t want to write getName() and setName(). In some cases it makes sense to write Get/Set methods rather than using properties, particularly if they could be expensive and you wish to emphasize that. However, you’d want to follow the .NET naming convention of PascalCase for methods, and you wouldn’t want a trivial property like this to be implemented with normal methods anyway – a property is much more idiomatic here.

C# 6

Hooray, we finally have proper read-only automatically implemented properties:

// This can only be assigned to within the constructor
public string Foo { get; }

Likewise for read-only properties which do need to do some work, you can use member-bodied properties:

public double Area => height * width;