Refactor -> Encapsulate Field. Can it ignore prefix like VS2005 does?

Hi,

I like to add m_ to class scoped variables, other people like to just add _ however when using ReSharpers Encapsulate Field option the default property name becomes M_ or an error where _ is used.

e.g.

refactor:
private int m_a;

gives:
public int M_a {

}

However when I do this with the VS2005 refactor it removes the m_ or the _ to give a more appropriately named property.

e.g.

VS2005 refactor:
private int m_a;

Gives
public int A {

}

I appreciate that if I make the variable camelCased (e.g. aVariable) the property becomes Pascal cased ( AVariable) but this then means the class is not cls compliant and is a great way to introduce some extra bugs.

Have I missed a trick or is their an option to get ReSharper to ignore prefixes as it gets really annoying having to edit each one (not to mention when I forget to edit them!)?

I do however love the way ReSharper puts the property in a more logical place than VS2005.

Also can I add my weight behind the request for a bulk refactor for Encapsulate Field. I often write out my properties for the class as private variables to start with then refactor each one in turn, would love to be able to select the lot and have a few clicks then to create all the properties for me (I’m getting more lazy as time goes on!). Also it’s really annoying how far down the menu the option for this is as I use it a lot but that’s just my preference, I guess I should do battle with VS’s key mapping and create a shortcut for it.

I’m using ReSharper 2.5.327.61


Thanks,


Steve.

7 comments
Comment actions Permalink

Hello Stephen,

You can change naming convention for fields and parameters by selecting Naming
Convention under Resharper Options.

Hi,

I like to add m_ to class scoped variables, other people like to just
add _ however when using ReSharpers Encapsulate Field option the
default property name becomes M_ or an error where _ is used.

e.g.

refactor:
private int m_a;
gives:
public int M_a {

}
However when I do this with the VS2005 refactor it removes the m_ or
the _ to give a more appropriately named property.

e.g.

VS2005 refactor:
private int m_a;
Gives
public int A {

}
I appreciate that if I make the variable camelCased (e.g. aVariable)
the property becomes Pascal cased ( AVariable) but this then means the
class is not cls compliant and is a great way to introduce some extra
bugs.

Have I missed a trick or is their an option to get ReSharper to ignore
prefixes as it gets really annoying having to edit each one (not to
mention when I forget to edit them!)?

I do however love the way ReSharper puts the property in a more
logical place than VS2005.

Also can I add my weight behind the request for a bulk refactor for
Encapsulate Field. I often write out my properties for the class as
private variables to start with then refactor each one in turn, would
love to be able to select the lot and have a few clicks then to create
all the properties for me (I’m getting more lazy as time goes on!).
Also it’s really annoying how far down the menu the option for this is
as I use it a lot but that’s just my preference, I guess I should do
battle with VS’s key mapping and create a shortcut for it.

I’m using ReSharper 2.5.327.61

Thanks,

Steve.



0
Comment actions Permalink

I appreciate that if I make the variable camelCased
(e.g. aVariable) the property becomes Pascal cased (
AVariable) but this then means the class is not cls
compliant and is a great way to introduce some extra
bugs.


Having a private member (E.G. a field) with the same spelling, but differing case, as a non private member (E.G. a property) does not break CLS compliance. The code would only become non CLS compliant if both members are non-private in scope.

Microsoft .Net naming recommendations are that private fields should be camel cased (leading lowercase character) with no common prefix and non private Properties should be pascal cased (leading uppercase character).

MSDN "Design Guidelines for Developing Class Libraries" (http://msdn2.microsoft.com/en-us/library/ms229042.aspx) is a good reference for the various MS recommended naming conventions.

IMHO, not using a common prefix on all fields improves intellisense lists. With a prefix of m_ against all fields, you have to type two extra characters on every single (field) completion list before you get any sort of uniqueness.

0
Comment actions Permalink

Matt,

Thank you that works a treat! So many options to get my head around!

Thanks,

Steve.

0
Comment actions Permalink

James,

Thanks for your reply.

In my defence I was having a dumb moment Re: CLS compliance. The compiler was giving me loads of warnings about “differing only in the case” causing cls compliance failure, what I totally failed to notice is that the fields were marked as protected (I didn’t author any of the the classes that were givving the warnings but that’s hardly an excuse). I’ll go and sit in a quite corner and feel stupid for the rest of the afternoon.

As far as the class library guidelines goes I appreciate that they do advice using camel case for local variables and not using a prefix. However I’m not a fan of this for a few reasons.

My first issue (and I’ve done this one way to many times) is that when I create a public property it’s all too easy to select the property from intellisense rather than the field – I blame my dyslexia for that, naturally this has a bad side effect and unfortunately no compiler warning, you only get to find this mistake when you exercise the code and get a stack overflow exception. It’s particularly noticeable if you add the property before you’ve added the field. (I’m liking ReSharpers recursion indicator!)

I find it easier to use the m_ to filter with intellisense to just give me the local fields, sometimes it can get all cluttered and difficult to see what’s what in the list and I find that the prefix helps the grouping/filtering and gets them out of the way when I’m looking for properties and debugging, but that’s just my preference as to the way I work.

This also helps bring my attention that I’m using a member variable as opposed to going through the property as case differences aren’t always that easy to spot and to highlight that I am using a member field and not a method scoped variable.

I appreciate that using the m_ isn’t all that aesthetically pleasing either but I can put up with that and a couple of extra key stokes to get what I feel are the benefits and stop my property recursion issues!

Needless to say who ever I’m working for I use the style they wish for, but when it’s my own stuff I like to use the m_, fortunately it turns out I can get ReSharper to live with my querks!


Cheers,


Steve.

0
Comment actions Permalink

Stephen Harrison schreef:

James,

Thanks for your reply.

>...

My first issue (and I’ve done this one way to many times) is that
when I create a public property it’s all too easy to select the
property from intellisense rather than the field – I blame my
dyslexia for that, naturally this has a bad side effect and
unfortunately no compiler warning, you only get to find this mistake
when you exercise the code and get a stack overflow exception. It’s
particularly noticeable if you add the property before you’ve added
the field. (I’m liking ReSharpers recursion indicator!)

>...


Cheers,


Steve.


I agree. It's one of the few rules we don't follow. It's not only when
you're coding the property itself, but also in all other places in the
class where you want to use that field or property.

BTW: I prefer to use the property in the class itself as well, except
for virtual properties in the constructor. I've had too many errors with
not properly initialized fields or flags.

Regards,
Erwin

0
Comment actions Permalink

Well, horses for courses. It is great that R# can accommodate so many differring styles.

I agree about accessing a field via its property, even in the field declaring class. I blogged about total field encapsulation (http://extraview.co.uk/blog/PermaLink,guid,3f47246e-1cea-4f48-aa45-3c1ffe7a4284.aspx) a while back and I have a link, from my post, to Microsoft's site where you can vote on getting this feature into the core language.

0
Comment actions Permalink

James and Erwin,

Thanks for your comments.

Indeed “horses for courses” sums it up well!

It is very sweet that ReSharper allows for the different styles, I’ve been using R# for some time now but haven’t spent anywhere near enough time trying to get to grips with the mass of options available, alas I found that quite a few of the defaults (such as the single line stuff and key mappings) aren’t to my style/work preference so I’ve tweaked lots of bits which is great that I’m able to do that – I feel for the R# testers as it must be a nightmare with so many different options to work through!

It makes me wonder what other tricks I’m missing, I shale have to go and read more of the 30 days of ReSharper blog entries to see if theirs some other obvious stuff I’m missing out on!

I like the property scoped field idea, alas voting was closed on it on Microsoft’s site.


Regards,

Steve.

0

Please sign in to leave a comment.