automatic code generation for properties

  • Thread starter Thread starter Abhishek Srivastava
  • Start date Start date
A

Abhishek Srivastava

Hello All,

There is a particular feature which I want to have in visual studio .net

suppose I create a class

ClassA
{
private string name;
private int age;
}

Then I right click on my code and say "generate properties".

And a property gets created (with capital for the first character ex.
Name, Age) for each of the private members of my class.

Can I do this is vs.net?

thanks for your help in advance.

regards,
Abhishek.
 
You can't do this right now. Whidbey will include refactoring, which might
have something similar, although it's more likely that you'll be able to
turn simple public members (as your example below) into public get/set
accessors paired with private members.

You can of course write an add-in that will do this.
 
Abhishek said:
Hello All,

There is a particular feature which I want to have in visual studio .net

suppose I create a class

ClassA
{
private string name;
private int age;
}

Then I right click on my code and say "generate properties".

And a property gets created (with capital for the first character ex.
Name, Age) for each of the private members of my class.

Can I do this is vs.net?

thanks for your help in advance.

regards,
Abhishek.

Check out this artical on code generation:
http://www.devcity.net/net/article.aspx?alias=codedom_1
 
In the next version, VS will have some built-in refactoring tools that do
similar things (more than just properties though).
Until then, do some searching on the net for VS add-ins. People have written
some that auto-generate properties and the like.

If you're willing to do some work yourself, you can actually create VS
macros that do exactly what you want. Just go to Tools->Macros, and you can
create a script that reads the current selection in the document window, and
uses the code DOM (document object model) to insert property statements, or
do whatever else you like. Macros are EXTREMELY underused IMO :-)

-Rob Teixeira [MVP]
 
Abhishek Srivastava said:
There is a particular feature which I want to have in visual studio .net

suppose I create a class

ClassA
{
private string name;
private int age;
}

Then I right click on my code and say "generate properties".

And a property gets created (with capital for the first character ex.
Name, Age) for each of the private members of my class.

Can I do this is vs.net?

Others have answered the question you've actually asked, but I'd like
to propose a different solution: namely a way of the C# language itself
changing to allow "simple" property definitions. The syntax is up for
grabs, but I'd suggest something like:

<AccessModifier> property <TypeName> <fieldName> [ = <initialValue>]
<PropertyName> {[get;][set;]}

For instance:

public property string name Name { get; }
protected property int height=10 Height {get; set; }

would be exactly equivalent to:

private string name;
public string Name
{
get { return name; }
}

private int height=10;
protected int Height
{
get { return height; }
set { height = value; }
}

XML documentation applied to the short form would either be applied to
the field, the property or both - up for grabs, but I'd favour the
property, with an automatic XML documentation for the field of "Field
backing the simple property <PropertyName>: <XML doc for PropertyName>"

I was seriously anti this a while ago, and argued fairly vehemently
against it - but I now believe it would make a lot of code
significantly simpler, and might persuade people to use properties
where they might otherwise use public fields just for convenience.

Whether or not one could declare the property to be virtual, I don't
know - and likewise exactly how different access modifiers for get/set
would work.
 
Whidbey will contain a lot of code shortcuts for this sort of thing.
Specifically for properties, the new IDE will allow you to type 'property'
followed by a tab which will automatically generate the following code
template:

private int _MyProperty;

public int MyProperty{
get{
return _MyProperty;
}
set{
_MyProperty=value;
}
}

You can then tab through the data type, private field name, and public
property name and change those as needed. For a live example of this, check
out the webcast:

http://msdn.microsoft.com/msdntv/episode.aspx?xml=episodes/en/20040219CSHARPDF/manifest.xml

Hope this helps.

--Eric
 
Jon Skeet said:
Abhishek Srivastava said:
There is a particular feature which I want to have in visual studio .net

suppose I create a class

ClassA
{
private string name;
private int age;
}

Then I right click on my code and say "generate properties".

And a property gets created (with capital for the first character ex.
Name, Age) for each of the private members of my class.

Can I do this is vs.net?

Others have answered the question you've actually asked, but I'd like
to propose a different solution: namely a way of the C# language itself
changing to allow "simple" property definitions. The syntax is up for
grabs, but I'd suggest something like:

<AccessModifier> property <TypeName> <fieldName> [ = <initialValue>]
<PropertyName> {[get;][set;]}

For instance:

public property string name Name { get; }
protected property int height=10 Height {get; set; }

would be exactly equivalent to:

private string name;
public string Name
{
get { return name; }
}

private int height=10;
protected int Height
{
get { return height; }
set { height = value; }
}

XML documentation applied to the short form would either be applied to
the field, the property or both - up for grabs, but I'd favour the
property, with an automatic XML documentation for the field of "Field
backing the simple property <PropertyName>: <XML doc for PropertyName>"

I was seriously anti this a while ago, and argued fairly vehemently
against it - but I now believe it would make a lot of code
significantly simpler, and might persuade people to use properties
where they might otherwise use public fields just for convenience.

Whether or not one could declare the property to be virtual, I don't
know - and likewise exactly how different access modifiers for get/set
would work.



I actually think some compiler shortcuts would be in order here. Instead of
manually naming the underlying field, I would take the approach events
without handlers do in C# currently, that is the compiler treats access to
an event without accessors as a direct access to the underlying field it
generates for the event. Using a syntax like

<AccessModifier> property <Type> <PropertyName>{<Accessors>;} =
<Initalization>;

public property string Name{get;} = "10";

Should be legal for the class that contains Name and in my opinion would be
cleaner. There are, of course, downsides, most notably trying to determine
which properties use special setters and which don't. However, with proper
application of the property keyword it would be possible. Add on the use of
read only public readonly property string Name{get;}, which like readonly
fields is only assignable in the constructor or at inilalization time, and I
think that there is a good possiblity for this.

As for your xml suggestion, this syntax could potentally make knowing the
field name as irrelevent as knowing the actual event field name in events,
however a reproducable field name like __$property_backer_<Name>; could be
used.

Also, it would be possible to provide a third accessor type for internal or
protected assignments, allowing protected members to use the internal,
direct field set instead of whatever is assigned for the set accessor. This
would have to be done with care, considering its not always clear which
assignment is wanted, but it would help to solve the protected field, public
getter\setter problem.

Now, I have no clue how to distinguish accessors with different
accessibility, I've yet to see how its achieved without this syntax so I
don't have any ideas from that. However, two potentials come to mind. The
C++ method like:

public property string Name{get;};

protected property string Name{set;} = "10";

or public property string Name
{
get;
private set;
}

where the accessibilty of the property applies by default(my preference I
think), or explicity like so:

property string Name
{
public get;
private set;
}

I'm not entirely sure about that yet though. The same thigns would go for
virtuality as well, I suppose. virtual on the property applies to all
non-private members, or virtual must be specified on each accessor. Emitting
code for implicit virtual properties wouldn't be difficult, its just getting
the syntax right.
 
Back
Top