Why this example of accessing private field is not correct in C#

Question

Let's say that we have:

class A{
   private int age;
   public void setAge(int age){
          if(age < 100)
            this.age = age;
   }
}

Why shouldn't I do it in C#? Please don't tell me: "because there are properties in C#". Why is this worse than properties?

Who says it is worse. If that's how you want to do it, do it. — David Heffernan, Jan 12 '14 at 18:36
What you're doing isn't necessarily incorrect, but you could also use get {} and set {} for public variables. — K. S., Jan 12 '14 at 18:39
I say here:http://stackoverflow.com/questions/21078168/what-is-the-difference-between-property-and-public-field/21078230#21078230 — , Jan 12 '14 at 18:39
Why do you think it's "not correct"? Are you getting an error? — Dour High Arch, Jan 12 '14 at 18:41
It's a matter of readability, flexibility, and convention. You should bear in mind that some nice features of the .NET framework are designed for use with properties, and things get complicated, break down, or simply don't work for data not exposed as properties. An obvious one is the **INotifyPropertyChanged** interface; another is **ComponentModel**. In general, it's a better idea to expose data elements as properties rather than implement getter/setter methods... if for no other reason than future-proofing your code. — Zenilogix, Jan 12 '14 at 18:58

score 2 · Answer 1 · answered Jan 12 '14 at 18:38

It is perfectly fine to do it in this manner. You can also use a property in C# to implement it. In the code above you have a backing field age and if you use a property, the compiler creates it for you.

The important thing is to control access to the private data member so you can do exactly what you did above - apply business rules to the code.

If you use properties, the code reads a little easier: a.Age = 5 vs. a.setAge(5) but that's personal preference (or coding guidelines if you are on a team).

score 1 · Answer 2 · answered Jan 12 '14 at 18:38

1

This is 100% legal and correct C# code. There is nothing fundamentally incorrect about it.

It is more idiomatic to use a property in C# for such a scenario. However this is not a requirement of the language, it's simply a recommended style choice

answered Jan 12 '14 at 18:38

JaredPar

733,204
149
1,241
1,454

score 0 · Answer 3 · answered Jan 12 '14 at 18:40

Properties are typically used in this case, because it's thought that:

a.Age = 30;
Show(a.Age);

is more fluent and sensible than:

a.setAge(30);
Show(a.getAge());

in that the first example reads more like spoken language, and seems to flow better.

The second example is not "incorrect", though. Use what you (and your team) are comfortable with. Although, I'd encourage you to give properties a try. Moving from Java, I found few downsides to their use.

score 0 · Answer 4 · answered Jan 12 '14 at 18:40

It's all about readability. If your team members are able to understand this code, it's okay. Moreover, I prefer to use exactly same approach, because it makes things much more clear, and I don't need to reinvent variable names that keep just the same thing.

But I'd modify it to:

   public void setAge(int age){
          if(age < 100)
            this.age = age;
          else
            throw new ArgumentException("age must be less than 100");
   }

Because others may expect that setAge will set age. And it's a bit confusing if it has limitations and has no any error messages.

BRAHIM Kamel · Answer 5 · 2014-01-12T18:58:00.723

It's right to do something like this but it's not recommended as by c# properties convention
From MSDN :

Unlike other members, properties should be given noun phrase or adjective names. That is because a property refers to data, and the name of the property reflects that. PascalCasing is always used for property names.

√ DO name properties using a noun, noun phrase, or adjective.

X DO NOT have properties that match the name of "Get" methods as in the following example:

public string TextWriter { get {...} set {...} } 
public string GetTextWriter(int value) { ... }

This pattern typically indicates that the property should really be a method. √ DO name collection properties with a plural phrase describing the items in the collection instead of using a singular phrase followed by "List" or "Collection."

√ DO name Boolean properties with an affirmative phrase (CanSeek instead of CantSeek). Optionally, you can also prefix Boolean properties with "Is," "Can," or "Has," but only where it adds value.

√ CONSIDER giving a property the same name as its type. For example, the following property correctly gets and sets an enum value named Color, so the property is named Color:

public enum Color {...}
public class Control {
    public Color Color { get {...} set {...} }
}

look at this explanation from CLR via C# (Jeffrey Richter)

public sealed class BitArray {
// This is the indexer's get accessor method.
public Boolean get_Item(Int32 bitPos) { /* ... */ }
// This is the indexer's set accessor method.
public void set_Item(Int32 bitPos, Boolean value) { /* ... */ }
}

The compiler automatically generates names for these methods by prepending get_ and set_ to the indexer name. Because the C# syntax for an indexer doesn’t allow the developer to specify an indexer name, the C# compiler team had to choose a default name to use for the accessor methods; they chose Item. Therefore, the method names emitted by the compiler are get_Item and set_Item.

Why this example of accessing private field is not correct in C#

5 Answers5