Naming Convention for Temporaries

[jehugaleahsa]

Hello:

Have you ever wanted a list of customer IDs, but had to get a list of
Customers first?

I am pretty conscientious about style and good variable names, so I am
wonder what other people do in certain situations when a temporary or
middle step is necessary.

IEnumerable<Customercustomers = getCustomers();
List<CustomerlistOfCustomers = new List<Customer>(customers);
List<intcustomerIds = listOfCustomers.ConvertAll<int>(delegate
(Customer current)
{
return current.ID;
});

listOfCustomers seems dirty to me. I mean, I could make that one line
of code, but then readibility suffers.

Just curious if other people have a better naming convention.

Thanks,
Travis

[Jeroen Mostert]

je**********@gmail.com wrote:

Have you ever wanted a list of customer IDs, but had to get a list of
Customers first?

Can't say that I have. :-)

I am pretty conscientious about style and good variable names, so I am
wonder what other people do in certain situations when a temporary or
middle step is necessary.

IEnumerable<Customercustomers = getCustomers();
List<CustomerlistOfCustomers = new List<Customer>(customers);
List<intcustomerIds = listOfCustomers.ConvertAll<int>(delegate
(Customer current)
{
return current.ID;
});

Let's see. No C# 3.0, I take it? Otherwise there'd be no need for the clumsy
delegate syntax. Or a temporary list.

I would not declare a temporary for "customers". There's no point to having
this as an intermediary result, since all you can do with it is enumerate it
(once, usually). So I'd just do a little renaming:

List<Customercustomers = new List<Customer>(getCustomers());

listOfCustomers seems dirty to me. I mean, I could make that one line
of code, but then readibility suffers.

Eye of the beholder, etc. I will say that there's no point worrying about
the names you should give to your temporary variables if you don't have the
temporary variables in the first place. And I wouldn't consider having an
explicit IEnumerable<in my code to make it more readable, on the contrary.
Having multiple variables that express a different "view" of the same data
usually gets quite bothersome (think having "customerIdString" and
"customerId" for the raw value and the parsed value, for example -- you can
think of better names, but it doesn't change the fact that you've got two
variables referring to the "same" data).

And as for less readable, it's nothing compared to stuffing *everything* in
one line:

List<intcustomerIds = new
List<Customer>(getCustomers()).ConvertAll<int>(del egate (Customer current) {
return current.ID; })));

Now that's what I'd call less readable. Thankfully we have LINQ now for
these one-liners...

--
J.

[Peter Duniho]

On Fri, 11 Jul 2008 07:36:35 -0700, je**********@gmail.com
<je**********@gmail.comwrote:

Have you ever wanted a list of customer IDs, but had to get a list of
Customers first?

I am pretty conscientious about style and good variable names, so I am
wonder what other people do in certain situations when a temporary or
middle step is necessary.

Well, since you asked... :)

One of the things I like about the Hungarian naming convention is that it
removes these sorts of "how do I name this variable?" questions. If you
need a variable that's simply a temporary holder for something, you simply
use the "T" suffix. For example, if the normal Hungarian tag would be
"customer", then a variable that's a temporary holder for the variable
would be "customerT".

It's not clear that you actually need a temporary variable in this case.
As Jeroen suggests, the code could be consolidated to avoid that need.
And even if you do find the code more readable using an intermediate
variable (which is a fine justification for doing so), you may not find
that particular situation compelling enough to start learning Hungarian.

But just in case, check out:
http://www.byteshift.de/msg/hungaria...n-doug-klunder

Keeping in mind, of course, that the article was written decades ago and
there's room for extending the concepts described there to take into
account longer type and variable names and new fundamental types that
exist in languages like Java and C#. It's a starting point, not the last
word.

And maybe even the Wikipedia article on the topic:
http://en.wikipedia.org/wiki/Hungarian_notation
(paying particular note to the distinction made between "systems" and
"apps" Hungarian...stay away, as far as possible, from the "systems"
dialect, as it's particularly pointless and awkward).

Pete

[Israel]

On Jul 11, 10:58*am, Jeroen Mostert <[e-mail]:

I would not declare a temporary for "customers". There's no point to having
this as an intermediary result, since all you can do with it is enumerateit

Unless there are significant performance issues (i.e. ones that a user
could possibly notice) then I opt to make as many intermediate
variables as possible just for debugging purposes. Nothing annoys me
more than debugging code like:

return SomeMethod( AnotherMethod( SomeObject.Property) );

And I want to see some intermediate variables. With a sufficiently
complex code base and various virtual method calls this style can get
you lost real quick and make you forgot what you were actually
debugging.

[Jeroen Mostert]

Israel wrote:

On Jul 11, 10:58 am, Jeroen Mostert <[e-mail]:

>I would not declare a temporary for "customers". There's no point to having
this as an intermediary result, since all you can do with it is enumerate it

Unless there are significant performance issues (i.e. ones that a user
could possibly notice) then I opt to make as many intermediate
variables as possible just for debugging purposes. Nothing annoys me
more than debugging code like:

return SomeMethod( AnotherMethod( SomeObject.Property) );

And I want to see some intermediate variables. With a sufficiently
complex code base and various virtual method calls this style can get
you lost real quick and make you forgot what you were actually
debugging.

Two points: Visual Studio has excellent support for debugging compound
expressions (press F9 in the right spot and you're good to go) and second,
while I agree with your sentiment in general, having an IEnumerable as an
intermediary can be worse than useless, since enumerating it can change its
state and make further debugging pointless.

--
J.

[Jeroen Mostert]

Jeroen Mostert wrote:

Israel wrote:

>On Jul 11, 10:58 am, Jeroen Mostert <[e-mail]:

>>I would not declare a temporary for "customers". There's no point to
having
this as an intermediary result, since all you can do with it is
enumerate it

Unless there are significant performance issues (i.e. ones that a user
could possibly notice) then I opt to make as many intermediate
variables as possible just for debugging purposes. Nothing annoys me
more than debugging code like:

return SomeMethod( AnotherMethod( SomeObject.Property) );

And I want to see some intermediate variables. With a sufficiently
complex code base and various virtual method calls this style can get
you lost real quick and make you forgot what you were actually
debugging.

Two points: Visual Studio has excellent support for debugging compound
expressions (press F9 in the right spot and you're good to go)

Eh, it's not as good as I remembered. It can't break on actual nested
expressions. You can break on the line and evaluate the subexpressions, of
course, but that's not the same thing.

The Immediate Window also relieves some of the hurt, but in general,
intermediaries are good. My point about IEnumerable intermediaries not being
so good stands, though.

--
J.

[Israel]

On Jul 11, 1:43*pm, Jeroen Mostert <[e-mail]:

Two points: Visual Studio has excellent support for debugging compound
expressions (press F9 in the right spot and you're good to go) and second,
while I agree with your sentiment in general, having an IEnumerable as an
intermediary can be worse than useless, since enumerating it can change its
state and make further debugging pointless.

I guess I'm not sure I follow the part about the IEnumerable. In a
situation like the one noted at the begining of this discussion thread
code like this:
IEnumerable<Customercustomers = getCustomers();
List<CustomerlistOfCustomers = new List<Customer>(customers);
Should be functionally equivilent to this code:
List<CustomerlistOfCustomers = new List<Customer>(getCustomers());

And I guess my point was that the first method (which separates out
the code into 2 lines) is the pattern I usually prefer to make
debugging easier.

[Jeroen Mostert]

Israel wrote:

On Jul 11, 1:43 pm, Jeroen Mostert <[e-mail]:

>Two points: Visual Studio has excellent support for debugging compound
expressions (press F9 in the right spot and you're good to go) and second,
while I agree with your sentiment in general, having an IEnumerable as an
intermediary can be worse than useless, since enumerating it can change its
state and make further debugging pointless.

I guess I'm not sure I follow the part about the IEnumerable. In a
situation like the one noted at the begining of this discussion thread
code like this:
IEnumerable<Customercustomers = getCustomers();
List<CustomerlistOfCustomers = new List<Customer>(customers);
Should be functionally equivilent to this code:
List<CustomerlistOfCustomers = new List<Customer>(getCustomers());

And I guess my point was that the first method (which separates out
the code into 2 lines) is the pattern I usually prefer to make
debugging easier.

My point was that evaluating an IEnumerable changes its state. If the
IEnumerable doesn't provide a usable .Reset() method (and many don't), then
you can't continue debugging the code. That's not particularly convenient.
If getCustomers() is safe to call more than once, you can reinitialize the
variable, but if you can do that then you might as well call getCustomers()
directly from the Immediate window or Quickwatch.

Using a temporary here makes sense if the IEnumerable is a custom
implementation (in other words, you're debugging the enumeration mechanism
itself) or if you need to quickly see if the IEnumerable is null, but for me
those cases are too rare to pre-emptively "temporarize" all my code. There's
good reason why the foreach-statement abstracts away from the IEnumerable
variable; they're almost never interesting on their own.

--
J.

[Jon Skeet [C# MVP]]

Jeroen Mostert <jm******@xs4all.nlwrote:

My point was that evaluating an IEnumerable changes its state. If the
IEnumerable doesn't provide a usable .Reset() method (and many don't), then
you can't continue debugging the code. That's not particularly convenient.
If getCustomers() is safe to call more than once, you can reinitialize the
variable, but if you can do that then you might as well call getCustomers()
directly from the Immediate window or Quickwatch.

One quick point: there's a big difference between IEnumerable and
IEnumerator. Reset is part of IEnumerator, and you're right that it's
rarely implemented. However, in many (not all, but many) cases you can
call GetEnumerator() multiple times on the same IEnumerable.

--
Jon Skeet - <sk***@pobox.com>
Web site: http://www.pobox.com/~skeet
Blog: http://www.msmvps.com/jon_skeet
C# in Depth: http://csharpindepth.com

[Jeroen Mostert]

Jon Skeet [C# MVP] wrote:

Jeroen Mostert <jm******@xs4all.nlwrote:

>My point was that evaluating an IEnumerable changes its state. If the
IEnumerable doesn't provide a usable .Reset() method (and many don't), then
you can't continue debugging the code. That's not particularly convenient.
If getCustomers() is safe to call more than once, you can reinitialize the
variable, but if you can do that then you might as well call getCustomers()
directly from the Immediate window or Quickwatch.

One quick point: there's a big difference between IEnumerable and
IEnumerator.

My Big Book of Excuses tells me that the appropriate response here is "I
knew that!" I'm not convinced it's a good one, though.

Reset is part of IEnumerator, and you're right that it's
rarely implemented. However, in many (not all, but many) cases you can
call GetEnumerator() multiple times on the same IEnumerable.

Yes, I see. Consulting my handy Book again, I'm now supposed to say "I'm
sorry, that pretty much invalidates everything I said and I'm sorry for
wasting everyone's time", but honestly, why would anybody say *that*? I'm
going to get a refund.

*mumbles something about sleep deprivation*

--
J.

[Jon Skeet [C# MVP]]

Jeroen Mostert <jm******@xs4all.nlwrote:

Reset is part of IEnumerator, and you're right that it's
rarely implemented. However, in many (not all, but many) cases you can
call GetEnumerator() multiple times on the same IEnumerable.

Yes, I see. Consulting my handy Book again, I'm now supposed to say "I'm
sorry, that pretty much invalidates everything I said and I'm sorry for
wasting everyone's time", but honestly, why would anybody say *that*? I'm
going to get a refund.

*mumbles something about sleep deprivation*

No need, because there *are* times when you really don't want to call
GetEnumerator() again. LINQ to SQL is a pretty obvious example :) Other
times there may be no way of enumerating again - if you're enumerating
a network stream, for example.

--
Jon Skeet - <sk***@pobox.com>
Web site: http://www.pobox.com/~skeet
Blog: http://www.msmvps.com/jon_skeet
C# in Depth: http://csharpindepth.com