0

Possible Duplicate:
C#: Can I remove “{ get; set; }”?

My code has hundreds of lines that look like this:

public string abc { get; set; }
public string def { get; set; }

All have the { get; set; } at the end of them.

What I am wondering is if there is a way that I can clean up my code and even remove the need for { get; set; } while still making them public.

I know it's not a huge problem but I would like to try and clean up my code as much as possible.

Community
  • 1
  • 1
Ally
  • 1
  • 1
  • 1
  • 9
    That *is* the least verbose way to implement properties. – Brian Rasmussen Apr 11 '11 at 10:22
  • 1
    Possible duplicate [question](http://stackoverflow.com/questions/1693875/c-can-i-remove-get-set) – KaeL Apr 11 '11 at 10:23
  • I think this code is the cleanest possibly, considering it's already hiding and abstracting functionality; any less and it wouldn't be a property. You *could* use `public string abc;` - but it's a member not a property. – Kieren Johnstone Apr 11 '11 at 10:25
  • if you do have a problem even typing them out, use the c# snippet `prop`. Type `prop` in the editor, when it is selected in the intellisense pres tab twice. You can also use the Visual Studio class designer to write properties for you. – gideon Apr 11 '11 at 10:28
  • 2
    @Kieren properties are members, as are indexers, methods, etc - I think you mean "field" – Marc Gravell Apr 11 '11 at 10:29
  • If this is the last thing that needs clean up, I say you did a good job already. You should go out and enjoy the sun. :) – Johann Blais Apr 11 '11 at 10:35

6 Answers6

9

Not nicely. It is the {get;set;} that is making them automatically implemented properties; without them they become fields. You really don't want public fields, so leave it alone.

Really, you aren't solving any problem here; leave it. This is normal (at least since automatically implemented properties were introduced), and the {get;set;} is not adding to the line count etc.

Marc Gravell
  • 1,026,079
  • 266
  • 2,566
  • 2,900
  • Why you _"really don't want public fields"?_ Why has this boilerplate mantra gone unchallenged for so long? Meyer['88] in [_Eifel_](https://en.wikipedia.org/wiki/Eiffel_(programming_language)) kept purposefully the same syntax for fields & properties, to facilitate refactoring. [Python' s "consenting adults" principle](https://python-guide-chinese.readthedocs.io/zh_CN/latest/writing/style.html#we-are-all-consenting-adults) suggest to use common sense and avoid blindfuly erecting walls between developers & clients of the code. – ankostis Jul 22 '21 at 11:17
3

You can, but they will no longer public properties and instead would take on the form of public variables (which certainly isn't preferential and would be frowned upon, to be sure, so use at your own discretion):

public string abc;
public string def;

I'd say keep them as properties, auto-implemented properties are a God-send and your concern is unfounded.

Grant Thomas
  • 44,454
  • 10
  • 85
  • 129
1

If you remove { get; set; }, you will get a public field instead of a public property. Properties are often the preferred way of exposing simple members of your classes since they allow you to hide their implementation and change it without breaking dependent components.

If you have lots of code repetition, consider using base classes/inheritance for common properties (and methods) to clean up your code.

Anders Fjeldstad
  • 10,724
  • 2
  • 33
  • 50
1

{ get; set; } means that you have setter and getter property (exactly telling those are auto-implemented properties) for a field. It's not a good idea to have public fields in the class and therefore you should encapsulate your fields with properties. So it's good that you have them.

Rafal Spacjer
  • 4,838
  • 2
  • 26
  • 34
  • Whyis it _"not a good idea to have public fields"?_ Where does this idea originate from? Meyer['88] in [_Eifel_](https://en.wikipedia.org/wiki/Eiffel_(programming_language)) kept purposefully the same syntax for fields & properties, to facilitate refactoring. [Python' s "consenting adults" principle](https://python-guide-chinese.readthedocs.io/zh_CN/latest/writing/style.html#we-are-all-consenting-adults) suggest to use common sense and avoid blindfuly erecting walls between developers & clients of the code. – ankostis Jul 22 '21 at 11:13
0

If there are classes with the same properties you could extend one another.

class Person
{
    public string Name { get; set; }
}

class Student : Person
{
    public string StudentId { get; set; }
}

class ShopKeeper : Person
{
    public Shop Shop { get; }
}

In the example above Student and ShopKeeper would inherit the property Name, which means you only have to write it once.

You can't make the get and set methods any simpler.

Kevin
  • 5,626
  • 3
  • 28
  • 41
0

:) you should have seen property with backing field like this below:

        private string _test;
        public string Test
        {
            get { return _test; }
            set { _test = value; }
        }

now that requires clean up :)

Bek Raupov
  • 3,782
  • 3
  • 24
  • 42