"Bad Form" to use public class variables without get & set?
-
Hey everyone, just wondering what your thoughts are on Get & Set! I've got a class in which I have two public variables. The class itself changes their values, and any calling class can also change the values. Is it "bad form" to just leave these variables public? Or should I turn these into class properties by doing:
private int _myvar; public int myvar { get { return _myvar; } set { _myvar = value; } }The class is so specialized that I don't need to do any checking during a "set" when I call the class methods. My instinct says that I'd get a microsecond or two of a performance boost by just leaving myvar as public, and eliminating the private/get/set/propery code. But I'm curious as if to this is bad form. I could see if I had to prevent a "set" operation, or perform a check on the value first- but I don't have to do either of these. Thanks! -Thomas -
Hey everyone, just wondering what your thoughts are on Get & Set! I've got a class in which I have two public variables. The class itself changes their values, and any calling class can also change the values. Is it "bad form" to just leave these variables public? Or should I turn these into class properties by doing:
private int _myvar; public int myvar { get { return _myvar; } set { _myvar = value; } }The class is so specialized that I don't need to do any checking during a "set" when I call the class methods. My instinct says that I'd get a microsecond or two of a performance boost by just leaving myvar as public, and eliminating the private/get/set/propery code. But I'm curious as if to this is bad form. I could see if I had to prevent a "set" operation, or perform a check on the value first- but I don't have to do either of these. Thanks! -ThomasThe main argument against public fields is one of compatibility. If you change the public field to a public property, then that is a breaking change. So, probably not a big deal for monolithic single EXE apps, but for class libraries it is a no-no. In C#, I usually just put the whole property on a single line -- that way it does not clutter up the code so much. There is one (experimental) .NET language takes care of this more elegantly, called Boo. It uses attributes to let you mark a private field as having a getter and/or setter, which is then auto-generated at compile time (by the Boo compiler).
-
The main argument against public fields is one of compatibility. If you change the public field to a public property, then that is a breaking change. So, probably not a big deal for monolithic single EXE apps, but for class libraries it is a no-no. In C#, I usually just put the whole property on a single line -- that way it does not clutter up the code so much. There is one (experimental) .NET language takes care of this more elegantly, called Boo. It uses attributes to let you mark a private field as having a getter and/or setter, which is then auto-generated at compile time (by the Boo compiler).
Virtually all the .NET framework uses get/set properties, even for lightweight structs (Point, Size, Rectangle, for example). The only times the framework exposes fields are static readonly fields; aside from that the standard seems to be to expose fields as properties. Judah Himango
-
The main argument against public fields is one of compatibility. If you change the public field to a public property, then that is a breaking change. So, probably not a big deal for monolithic single EXE apps, but for class libraries it is a no-no. In C#, I usually just put the whole property on a single line -- that way it does not clutter up the code so much. There is one (experimental) .NET language takes care of this more elegantly, called Boo. It uses attributes to let you mark a private field as having a getter and/or setter, which is then auto-generated at compile time (by the Boo compiler).
Steven Campbell wrote: There is one (experimental) .NET language takes care of this more elegantly, called Boo. It uses attributes to let you mark a private field as having a getter and/or setter, which is then auto-generated at compile time (by the Boo compiler). C++/CLI has something similar, called trivial properties. Basically, you say:
property int Somethingand compiler creates a private variable and a property for you.
My programming blahblahblah blog. If you ever find anything useful here, please let me know to remove it.
-
Steven Campbell wrote: There is one (experimental) .NET language takes care of this more elegantly, called Boo. It uses attributes to let you mark a private field as having a getter and/or setter, which is then auto-generated at compile time (by the Boo compiler). C++/CLI has something similar, called trivial properties. Basically, you say:
property int Somethingand compiler creates a private variable and a property for you.
My programming blahblahblah blog. If you ever find anything useful here, please let me know to remove it.
Which in turn generate the appropriate
get_xandset_xmethod calls. - Nick Parker
My Blog | My Articles -
Virtually all the .NET framework uses get/set properties, even for lightweight structs (Point, Size, Rectangle, for example). The only times the framework exposes fields are static readonly fields; aside from that the standard seems to be to expose fields as properties. Judah Himango
Steven & Judah, thanks! I guess I'll change those fields into properties- I hate "breaking style". The class is sealed- it's basically for some help during a system data migration- but as trivial as it is, I don't want any poor coding habits popping up! -Thomas