C# coding guidelines: use "this." or not when referring to member fields/properties within the object?

[Dave]

I'm never quite sure whether to use "this." or not when referring to fields
or properties in the same class. It obviously works just fine without it
but sometimes I wonder if using this. consistently may make the code easier
to understand for someone else, etc. Using "this." makes it immediately
clear, for example, that the variable being referred to is a member of the
same class and is not declared in the method as a local variable.

Not a big deal but this has been on my mind since I've been coding C#.

Also, while I'm thinking about it: should a class internally reference
properties by the property name or by the private variable that stores the
value? I've done both. I suppose the main thing is if the property does
more than just set the value of the private variable then the class code
should use the property name instead of the private variable.

Does Microsoft's C# coding guidelines cover either of these questions?
Where can I find the most up-to-date copy of their C# coding guidelines?

[Michael C]

"Nick Hounsome" <Ne**@NickHounsome.Me.Uk> wrote in message
news:CG*********************@fe1.news.blueyonder.c o.uk...

If you don't use a prefix then your fields will be all mixed up with your
methods and properties and also the methods and properties of your bases
and interfaces in the intellisense list.

I often forget what I've called my fields, particularly when designing
forms where there is always a LOT of base stuff in the intellisense list.

I just type this.m_ and I have a shortlist of the stuff I actually care
about to pick from.

You misread my post.

Michael

[Jon Skeet [C# MVP]]

Michael C <no****@nospam.com> wrote:

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP***********************@msnews.microsoft.co m...

What makes you think that reordering affects performance though? Have
you measured it (in C#, not VB6)?

It has to do a comparison to each value presumably starting at the top.
Putting a commonly used item towards the bottom should result in more
comparisons.

That's not how switch/case works - at least not when there are lots of
contiuguous entries. A table is used instead, to avoid doing that many
comparisons. When the entries are sparse, things get a bit trickier -
but I doubt that the performance is improved by moving things around. I
believe (after a short time of investigation, but nothing conclusive)
that the compiler will compile the code of the cases in the order you
specify, but do the comparisons in the same way whatever you do, just
jumping to different places. Of course, the JIT gets another stab at
optimisation too.

That's the thing with these micro-optimisations - they're *definitely*
not worth doing if you don't even know whether they'll help. The time
spent benchmarking this kind of thing (unless you happen to just be
interested and do it in spare time) is likely to be far more
"expensive" than any performance gains achieved.

I *think* there's a way you can avoid it, but I can't remember it.

You could use the DebuggerStepThroughAttribute.

That's the one!

If you think you won't want to step into those properties in general, I
believe there's an attribute you can apply to stop the debugger from
doing it. I'm blowed if I can find the name of it though :(

It used to be applied to the designer generated code in InitializeComponent
I believe but doesn't look like it is anymore.

Well, using the Length property is minisculy faster in C#/.NET too -
but personally I would still use if (x=="") because I find that easier
to read. Others find the .Length property easier to read, so they use
that - it's fine.

I don't think there's much difference in readability myself so use the
faster.

Well, there isn't much difference in readability - but there isn't much
difference is speed either. I think in most cases you're more likely to
waste a second of engineering time reading the code than you are to
waste a second of computing time running the slower code. I value
engieneering time higher than computing time.

Now, people will use #1 because they think it makes it faster to only
look at the Count property once. In fact, #2 is faster than #1 (I
believe) because the JIT is able to make use of that common pattern and
optimise away the bounds checks - at least in some situations. (It may
be for arrays but not lists - I honestly can't remember at the minute,
and it may well change between CLR versions.)

Interesting. I would have used #1 when I needed the index.

Again, making the code a bit less readable for a minute difference in
speed, which may even be the wrong way!

But do you go out of your way to make tiny changes to the code which
take it away from the path of clearest readability, just for the sake
of performance which is probably insignificant? How would you go about
iterating through a list in your normal code?

Generally I would use #3 but wouldn't think it was the end of the world if
#1 or #2 was used when #3 could have been. It's possible you are
"micro-optimising" readability if you are using things like (X=="") instead
of len because of readability. I wouldn't consider readability down to that
level.

Whereas I view readability as absolutely king. Anything which
interrupts the flow of thoughts even slightly could cost time. In this
case, having an extra variable to think about could easily make someone
have to check something they wouldn't have to otherwise. (Heck, to
start with you need to check that the loop bounds look correct.)

The thing about this is that I don't have to deviate from natural
coding to do it - the most natural way of expressing the code when you
think of it in the first place is usually the most natural way of
reading it too. That's not true when you start bending the code to
achieve performance gains which will be negligible if they exist at
all.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[Christoph Nahr]

On Mon, 24 Apr 2006 11:44:12 +1000, "Michael C" <no****@nospam.com>
wrote:

Interesting, I done some testing and #3 was fastest (578ms), then #2 (469ms)
then #1 (406ms). The code I used is below.

foreach is fastest in your test case because you're using an array.
For collections that implement ICollection but also have a fast
indexer (such as List<> or ArrayList) foreach would be slower than
using an indexed loop. On the other hand, for collections with a slow
indexer but a fast enumerator the foreach loop would be faster...
--
http://www.kynosarges.de

[Nick Hounsome]

"Michael C" <no****@nospam.com> wrote in message
news:e9**************@TK2MSFTNGP03.phx.gbl...

"Nick Hounsome" <Ne**@NickHounsome.Me.Uk> wrote in message
news:CG*********************@fe1.news.blueyonder.c o.uk...

If you don't use a prefix then your fields will be all mixed up with your
methods and properties and also the methods and properties of your bases
and interfaces in the intellisense list.

I often forget what I've called my fields, particularly when designing
forms where there is always a LOT of base stuff in the intellisense list.

I just type this.m_ and I have a shortlist of the stuff I actually care
about to pick from.

You misread my post.

Ooops.

Personally I find that m_ is clearer than just m and I find _ ugly,
particularly next to "." .

[Willy Denoyette [MVP]]

"Michael C" <no****@nospam.com> wrote in message
news:eU**************@TK2MSFTNGP04.phx.gbl...
| "Michael C" <no****@nospam.com> wrote in message
| news:el**************@TK2MSFTNGP04.phx.gbl...
| > Interesting, I done some testing and #3 was fastest (578ms), then #2
| > (469ms) then #1 (406ms). The code I used is below.
|
| Oops, times were back to front, should be:
| #1 578ms
| #2 469ms
| #3 406ms
|
| Michael
|
|

Not surprising when you do this :
_ints[0] = i;

in #3, instead of this:
_ints[i]++;
like in #1 and #2.
These are two different operations, which invalidates the results.
Another thing you need to do is to warm-up the caches, before you run
micro-benchmarks like this, now #1 takes the hit of warming-up the caches,
so you need to run #1 once before actually timing.

With both corrections in place I measured:
#1: 226 ms
#2: 225 ms
#3: 284 ms

See #1 and #2 are (obviously) equaly fast, while #3 is the slowest.

Compare this to:
#1: 349 ms
#2: 213 ms
#3: 150 ms
.... when ran without the corrections.
See how easy it is to draw wrong conclusions when running micro benchmarks?

Willy.

[Mehdi]

On Mon, 24 Apr 2006 05:30:18 GMT, Nick Hounsome wrote:

It's a good idea to use both "this" and m_.

"this" gives you intellisense which elliminates typos and m_ makes it easier
to home in on your fields in the intellisense list.

In case some are not aware, in VS 2003, instead of using "this." to get the
intellinsense pop-up you can simply press Ctrl-space. This is probably the
most essential shortcut in this version of VS.

[Michael C]

"Nick Hounsome" <Ne**@NickHounsome.Me.Uk> wrote in message news:fk%2g.5304

Ooops.

Personally I find that m_ is clearer than just m and I find _ ugly,
particularly next to "." .

_ is ugly but I don't use it next to . There's no reason to prefix a module
level var with this if it starts with an _ because the _ tells you it is
part of this. I think m_ is uglier personally while just a plain m is the
least ugly although I don't use it.

Michael

[riscy]

This is very interesting read, however in my view, warming up the cache
should be part ot the timing measurement because 'warming up' is part
of the loop coding. Unless you have to very good reason why to excludes
it.

But it is very interesting observation....

In the end of the day, PC is so fast, the micro-benchmark may not be
essential as it use to be with 8080!.

It was a pity the window boot process is still slow, regardless how
powerful the processor can be!.

Riscy

Willy Denoyette [MVP] wrote:

"Michael C" <no****@nospam.com> wrote in message
news:eU**************@TK2MSFTNGP04.phx.gbl...
| "Michael C" <no****@nospam.com> wrote in message
| news:el**************@TK2MSFTNGP04.phx.gbl...
| > Interesting, I done some testing and #3 was fastest (578ms), then #2
| > (469ms) then #1 (406ms). The code I used is below.
|
| Oops, times were back to front, should be:
| #1 578ms
| #2 469ms
| #3 406ms
|
| Michael
|
|

Not surprising when you do this :
_ints[0] = i;

in #3, instead of this:
_ints[i]++;
like in #1 and #2.
These are two different operations, which invalidates the results.
Another thing you need to do is to warm-up the caches, before you run
micro-benchmarks like this, now #1 takes the hit of warming-up the caches,
so you need to run #1 once before actually timing.

With both corrections in place I measured:
#1: 226 ms
#2: 225 ms
#3: 284 ms

See #1 and #2 are (obviously) equaly fast, while #3 is the slowest.

Compare this to:
#1: 349 ms
#2: 213 ms
#3: 150 ms
... when ran without the corrections.
See how easy it is to draw wrong conclusions when running micro benchmarks?

Willy.

[Willy Denoyette [MVP]]

<ri***@onetel.com> wrote in message
news:11**********************@e56g2000cwe.googlegr oups.com...
| This is very interesting read, however in my view, warming up the cache
| should be part ot the timing measurement because 'warming up' is part
| of the loop coding. Unless you have to very good reason why to excludes
| it.
|

If you don't warmup the caches (L1 instruction/data), you favor the test #2
over #1, leading to false results. Another observation is that the GC kicks
in during the first test run, this is because the Gen0 threshold is in
general reached after the process initialized the CLR and brought in the
initially required objects. So normally you should force a GC as well after
you ran the first test to warmup the caches.
So the sequence I've used looks like:
run #x
GC.Collect
start timeing
run #1
stop timing
start timing
run #2
stop timing
....

| But it is very interesting observation....
|
| In the end of the day, PC is so fast, the micro-benchmark may not be
| essential as it use to be with 8080!.
|

Note that I don't care at all about the results of micro benchmarks like
these, they have no value other than prove that one construct may be
somewhat faster than another when run standalone, but the speed differences
fade away rapidly in a real world application.

| It was a pity the window boot process is still slow, regardless how
| powerful the processor can be!.
|

Take care, while processors are getting faster every day, other crucial
resources are not.
Especially the memory system is becomming a real issue.

Willy.

| Riscy
|
| Willy Denoyette [MVP] wrote:
| > "Michael C" <no****@nospam.com> wrote in message
| > news:eU**************@TK2MSFTNGP04.phx.gbl...
| > | "Michael C" <no****@nospam.com> wrote in message
| > | news:el**************@TK2MSFTNGP04.phx.gbl...
| > | > Interesting, I done some testing and #3 was fastest (578ms), then #2
| > | > (469ms) then #1 (406ms). The code I used is below.
| > |
| > | Oops, times were back to front, should be:
| > | #1 578ms
| > | #2 469ms
| > | #3 406ms
| > |
| > | Michael
| > |
| > |
| >
| > Not surprising when you do this :
| > _ints[0] = i;
| >
| > in #3, instead of this:
| > _ints[i]++;
| > like in #1 and #2.
| > These are two different operations, which invalidates the results.
| > Another thing you need to do is to warm-up the caches, before you run
| > micro-benchmarks like this, now #1 takes the hit of warming-up the
caches,
| > so you need to run #1 once before actually timing.
| >
| > With both corrections in place I measured:
| > #1: 226 ms
| > #2: 225 ms
| > #3: 284 ms
| >
| > See #1 and #2 are (obviously) equaly fast, while #3 is the slowest.
| >
| > Compare this to:
| > #1: 349 ms
| > #2: 213 ms
| > #3: 150 ms
| > ... when ran without the corrections.
| > See how easy it is to draw wrong conclusions when running micro
benchmarks?
| >
| > Willy.
|

[Willy Denoyette [MVP]]

<ri***@onetel.com> wrote in message
news:11**********************@e56g2000cwe.googlegr oups.com...
| This is very interesting read, however in my view, warming up the cache
| should be part ot the timing measurement because 'warming up' is part
| of the loop coding. Unless you have to very good reason why to excludes
| it.
|

If you don't warmup the caches (L1 instruction/data), you favor the test #2
over #1, leading to false results. Another observation is that the GC kicks
in during the first test run, this is because the Gen0 threshold is in
general reached after the process initialized the CLR and brought in the
initially required objects. So normally you should force a GC as well after
you ran the first test to warmup the caches.
So the sequence I've used looks like:
run #x
GC.Collect
start timeing
run #1
stop timing
start timing
run #2
stop timing
....

| But it is very interesting observation....
|
| In the end of the day, PC is so fast, the micro-benchmark may not be
| essential as it use to be with 8080!.
|

Note that I don't care at all about the results of micro benchmarks like
these, they have no value other than prove that one construct may be
somewhat faster than another when run standalone, but the speed differences
fade away rapidly in a real world application.

| It was a pity the window boot process is still slow, regardless how
| powerful the processor can be!.
|

Take care, while processors are getting faster every day, other crucial
resources are not.
Especially the memory system is becomming a real issue.

Willy.

| Riscy
|
| Willy Denoyette [MVP] wrote:
| > "Michael C" <no****@nospam.com> wrote in message
| > news:eU**************@TK2MSFTNGP04.phx.gbl...
| > | "Michael C" <no****@nospam.com> wrote in message
| > | news:el**************@TK2MSFTNGP04.phx.gbl...
| > | > Interesting, I done some testing and #3 was fastest (578ms), then #2
| > | > (469ms) then #1 (406ms). The code I used is below.
| > |
| > | Oops, times were back to front, should be:
| > | #1 578ms
| > | #2 469ms
| > | #3 406ms
| > |
| > | Michael
| > |
| > |
| >
| > Not surprising when you do this :
| > _ints[0] = i;
| >
| > in #3, instead of this:
| > _ints[i]++;
| > like in #1 and #2.
| > These are two different operations, which invalidates the results.
| > Another thing you need to do is to warm-up the caches, before you run
| > micro-benchmarks like this, now #1 takes the hit of warming-up the
caches,
| > so you need to run #1 once before actually timing.
| >
| > With both corrections in place I measured:
| > #1: 226 ms
| > #2: 225 ms
| > #3: 284 ms
| >
| > See #1 and #2 are (obviously) equaly fast, while #3 is the slowest.
| >
| > Compare this to:
| > #1: 349 ms
| > #2: 213 ms
| > #3: 150 ms
| > ... when ran without the corrections.
| > See how easy it is to draw wrong conclusions when running micro
benchmarks?
| >
| > Willy.
|

[Michael C]

"Mehdi" <vi****@REMOVEME.gmail.com> wrote in message
news:14******************************@40tude.net.. .

On Mon, 24 Apr 2006 05:30:18 GMT, Nick Hounsome wrote:

It's a good idea to use both "this" and m_.

"this" gives you intellisense which elliminates typos and m_ makes it
easier
to home in on your fields in the intellisense list.

In case some are not aware, in VS 2003, instead of using "this." to get
the
intellinsense pop-up you can simply press Ctrl-space. This is probably the
most essential shortcut in this version of VS.

Ctrl space dates back to visual basic 5 and possibly C before that.

Michael