Using "Me"

  • Thread starter Thread starter Harry Strybos
  • Start date Start date
H

Harry Strybos

Hi all

I use DevExpress CodeRush/Refactor Pro etc and I notice this suite advises
against using the "Me" qualifier, claiming it is redundant.

My concept was that full qualification of an object method was a good idea
(in any project)? e.g:

Dim SomeObject as MyProject.Workflow.GreatObject as opposed to Dim
SomeObject as GreatObject.

And in refering to SomeObject* I usually refer to it in a WinForm project as
Me.SomeObject.

Hope I am making this clear. Seems more readable, however, is there a
performance hit :(

*VS2008 VB.Net SP1 with Sql Server 2008 SP1

Thanks for any advice

Harry
 
Full qualification makes the code harder to read... IMO this is mostly a
matter of frequency. If this is an exceptionnal usage using the full
qualified name is enough. If you keep using the same things over and over
then importing the namespace is likely better.

Using Me is a bit like importing a namespace but still using the fully
qualified name.

You can check the IL but it should generate the same code...

In some products you can choose wether or not a rule is to be applied (using
Me is not my personal preference but the main point is to be convinced
yourself about the rules you follow, not to blindly apply them)....
 
Harry,

Yes "And",

It is also complaining that it is done in the by designer generated code.

In my opinion, does it says something about DevExpress

Just my opinion,

Cor
 
Hello Harry,
I use DevExpress CodeRush/Refactor Pro etc and I notice this suite
advises against using the "Me" qualifier, claiming it is redundant.

My concept was that full qualification of an object method was a good
idea (in any project)? e.g:
Click to expand...

CodeIssues are suggestions.... Not all of which are based on speed, but some
on readability grounds.

What is percieved as more or less readable is a personal choice however

Each *CodeIssue* can be turned off independantly on a per solution, project
or permanent basis.

I personally see "Me" or "this" (in C#) as a "naming" code smell. It suggests
that you are having to qualify something which maybe does not need to be.

Again this is a personal choice.

Might I ask which version of Coderush you are working with ?
 
Hello Cor Ligthert[MVP],
It is also complaining that it is done in the by designer generated
code.
Click to expand...

This certainly has been the case in the past... I see fewer of these with
every build.

DevExpress welcome any and all bug reports and suggestions in their Support
Center ( http://www.devexpress.com/sc/ )

I'm curious which version of Coderush you are using Cor?

Latest official version being 9.1.5 with an early Alpha available for 9.2.0
 
Harry Strybos said:
Hi all

I use DevExpress CodeRush/Refactor Pro etc and I notice this suite advises
against using the "Me" qualifier, claiming it is redundant.

My concept was that full qualification of an object method was a good idea
(in any project)? e.g:

Dim SomeObject as MyProject.Workflow.GreatObject as opposed to Dim
SomeObject as GreatObject.

And in refering to SomeObject* I usually refer to it in a WinForm project
as Me.SomeObject.

Hope I am making this clear. Seems more readable, however, is there a
performance hit :(

*VS2008 VB.Net SP1 with Sql Server 2008 SP1

Thanks for any advice

Harry
Click to expand...

I use Me all the time but only for the Intellisence that it offers.

LS
 
Rory Becker said:
Hello Harry,


CodeIssues are suggestions.... Not all of which are based on speed, but
some on readability grounds.

What is percieved as more or less readable is a personal choice however

Each *CodeIssue* can be turned off independantly on a per solution,
project or permanent basis.

I personally see "Me" or "this" (in C#) as a "naming" code smell. It
suggests that you are having to qualify something which maybe does not
need to be.

Again this is a personal choice.

Might I ask which version of Coderush you are working with ?
Click to expand...

I am using 9.1.5 My general comment on CodeRush is that it is brilliant.
Just was curious about the "Me" suggestion.
 
There is no practical difference when naming collissions aren't an issue.
The IL will wind up the same either way. It's simply a matter of
preference. If you are the only Harry in the room, I can say "Harry", if
not, I'll need to be more specific, but either way I'll get the right
"Harry".

-Scott
 
Harry Strybos said:
Hi all

I use DevExpress CodeRush/Refactor Pro etc and I notice this suite advises
against using the "Me" qualifier, claiming it is redundant.

My concept was that full qualification of an object method was a good idea
(in any project)? e.g:

Dim SomeObject as MyProject.Workflow.GreatObject as opposed to Dim
SomeObject as GreatObject.

And in refering to SomeObject* I usually refer to it in a WinForm project
as Me.SomeObject.

Hope I am making this clear. Seems more readable, however, is there a
performance hit :(

*VS2008 VB.Net SP1 with Sql Server 2008 SP1

Thanks for any advice

Harry
Click to expand...

Class SomeClass
Private myVar As Integer = 0
Public Sub New(ByVal myVar As Integer)
Me.myVar = myVar
End Sub
End Class

In the above case, you HAVE to specify Me.myVar in order to set it in the
constructor. I also agree that when it's not needed, it's more or less a
calling convention. Personally, I only use Me for calling properties and
when local variables conflict with other members of the class.

HTH,
Mythran
 
Harry Strybos said:
Hi all

I use DevExpress CodeRush/Refactor Pro etc and I notice this suite advises
against using the "Me" qualifier, claiming it is redundant.

My concept was that full qualification of an object method was a good idea
(in any project)? e.g:

Dim SomeObject as MyProject.Workflow.GreatObject as opposed to Dim
SomeObject as GreatObject.

And in refering to SomeObject* I usually refer to it in a WinForm project
as Me.SomeObject.

Hope I am making this clear. Seems more readable, however, is there a
performance hit :(

*VS2008 VB.Net SP1 with Sql Server 2008 SP1

Thanks for any advice

Harry
Click to expand...
Thanks for all your advice. I was actually more interested in whether there
was an increase in complier efficiency, as opposed to readability. Guess
none of you guys have Microsoft Mind Reader 1.0 installed :)
 
Harry said:
Thanks for all your advice. I was actually more interested in whether there
was an increase in complier efficiency, as opposed to readability. Guess
none of you guys have Microsoft Mind Reader 1.0 installed :)
Click to expand...

Depends upon what you mean by compiler efficiency. If you mean
efficiency of the resulting compiled code, then no, there's no increase
in efficiency.

If you mean does it compile faster, being a mind reader won't help.
It'll depend upon how the tokenizer works
 
That's less of an explanation of "Me" vs. the merits of fully qualifying a
type member that confilicts with another member that is also in scope.
 
As I indicated in my last message, there is no practical difference between
fully qualifying a member with "Me" or not. The compiles IL is the same
either way.

-Scott
 
It could also be cited as an example of using "Me" to disguise poor choice
of variable names.
 
Scott M. said:
As I indicated in my last message, there is no practical difference between
fully qualifying a member with "Me" or not. The compiles IL is the same
either way.
Click to expand...

Uhm, I pretty much said this when I said there's no increase in
efficiency in the compiled output.

If you need an expansion of that, then here: It's pretty much
guaranteed that the two will compile to the same IL and not just do so
in some particular instance -- not mathematically, but based upon how
you'd have to implement it to get that as the result. And in order to
do otherwise, you'd have to know that you were dealing with the hidden
instance parameter, but instead of using the normal method of accessing
it, you'd create a new variable, assign it the value of the instance
parameter, and then use that to access instance values.


And the speed of compilation still depends upon how the tokenizer
works, but I'd be extremely surprised if one was significantly faster
than the other.
 
No. Still what constitutes a "poor" choice of a variable name is highly
subjective. Your explanation, while not incorrect, speaks more to the issue
of fully qualifying a type so the compiler doesn't have to deal with an
ambiguous reference. It really doesn't get to the heart of what the actual
keword "Me" represents.

-Scott
 
My reply was meant for Harry, not you. Sorry.


J.B. Moreno said:
Uhm, I pretty much said this when I said there's no increase in
efficiency in the compiled output.

If you need an expansion of that, then here: It's pretty much
guaranteed that the two will compile to the same IL and not just do so
in some particular instance -- not mathematically, but based upon how
you'd have to implement it to get that as the result. And in order to
do otherwise, you'd have to know that you were dealing with the hidden
instance parameter, but instead of using the normal method of accessing
it, you'd create a new variable, assign it the value of the instance
parameter, and then use that to access instance values.


And the speed of compilation still depends upon how the tokenizer
works, but I'd be extremely surprised if one was significantly faster
than the other.
Click to expand...
 
I consider anything a "poor" variable name if it starts with a key word.
Java programs like to start variables with my, but my is a key word in
VB.NET so I'd pick something else unique. Personally I'd go with a word or
abbreviation which identifies the programmer or a company they're writing
for. John Smith might create a variable named jsmFieldValue.
I'm a novice at VB.NET but as best I can tell the Me keyword is similar to
the Java keyword #this!
 
I think you have missed one important point here.

No one is talking about making variables called MeSomething, rather they are
talking about qualifying a variable with the Me keyword as in Me.TypeName.
So, instead of using "Me" as *part* of the name, we are talking about fully
qualifying the name to differentiate it from a local name.


-Scott
 
The problem in this example wasn't the name as such, but that the name used
for the variable in the parameter list was the same as that used for a
variable already declared at a higher level. Without the additional
qualification the programmer would have typed the line

myVar = myVar

and if that isn't a warning that there was a problem with poor choice of
variable names then I don't know what is.
 
Back
Top