0

Whenever I tell Visual Studio to create getters and setters it generates the following code:

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

This code is not easy for me to understand. What would be much easier to work with, for me, would be the following:

    public string GetName()
    {
        return name;
    }

    public void SetName(string _name)
    {
        name = _name;
    }

I'd like to know if it is bad practice to write my own functions for get/set.

Christian Neverdal
  • 5,655
  • 6
  • 38
  • 93
  • 5
    What is it about properties that you find difficult to understand? – DGibbs Jul 01 '15 at 12:08
  • I don't understand why it's not easy for you to understand the first method. Also there are the shortcut: type "propfull" + 2*Tab and visual studio generate automatically this one. There is nothing to understand. – Neyoh Jul 01 '15 at 12:14
  • In given example you can use [auto-properties](http://stackoverflow.com/q/9304/1997232), they are mostly used when you don't need any logic inside getter/setter. – Sinatr Jul 01 '15 at 12:14
  • 6
    When in Rome, do as Romans do. When you program in C#, you use the C# conventions..., when you program in Java, you use the Java conventions (C# vs Java in this case is properties vs getter/setter methods) – xanatos Jul 01 '15 at 12:15
  • Why it is hard understand? When accessing these getters and setters I thought the logic way of doing this would be something like: ClassName.Variable.Set ...... But I guess that will change as I get more experienced :) – Falco Renierkens Jul 01 '15 at 12:30

2 Answers2

10

Yes. Because now your code is hard for everyone else to understand.

The .NET convention is to use properties. With the first piece of code I can do someObject.Name = "hello"; or string name = someObject.Name; and I've a good idea what that means without even looking for the documentation of Name.

With yours I have to learn more about your strange class to learn how to use it. I'm also going to worry that there's some caveat to your SetName() and GetName() methods that I should know about that prompted you to design your class so strangely. Not finding a description of this caveat in the documentation, I'm going to be nervous about using it.

Jon Hanna
  • 110,372
  • 10
  • 146
  • 251
  • Ah I understand what you mean. I now also understand what advantage using the first piece of code offers. Hope you didn't mind answering my stupid question, haha. I'm still new to the club. – Falco Renierkens Jul 01 '15 at 12:48
  • It's not a stupid question so much as a newbie question, of the sort that would likely have become obvious to you as you progressed, but how were you to know that? Incidentally, when your properties are as simple as that in your example you can do `public string Name{ get; set; }` and the backing filed and code is done for you, but leaving you with the option to change it to something more complicated in the future if necessary. – Jon Hanna Jul 01 '15 at 13:05
2

The short answer is Yes.

Ask yourself why you would want to? A property is essentially a method when written this way. If, for example, you wanted to notify other areas of code that the name changed you could do the following:

private string name;
public string Name
{
    get { return name; }
    set 
    {
        test = value;
        FireSomeChangedEvent("Name");
    }
}

Just be careful about what logic you do add. It is also bad practice to add value setting logic for other properties (i.e. setting LastName value in the setter of Name); this can become a debugging nightmare.

Also, if you do not need to add additional logic to the getter or setter, it's quite acceptable to use the following syntax rather than the private variable-backed example you used.

public string Name {get; set;} 
alan
  • 6,705
  • 9
  • 40
  • 70
  • Ah okay! Thanks for the quick responses guys. I guess it would be wise to just look a bit more at the default way of doing this. – Falco Renierkens Jul 01 '15 at 12:25
  • If you do not require the additional functionality, it's quite acceptable to follow the standard public string Name {get; set;} syntax rather than the private variable-backed example you used. I'll update my answer with these details. – alan Jul 01 '15 at 12:28
  • 1
    Also there are some other implications in not using properties, e.g. databinding will no longer work. – sloth Jul 01 '15 at 12:40