Naming Convention for Temporaries

J

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<Customer> customers = getCustomers();
List<Customer> listOfCustomers = new List<Customer>(customers);
List<int> customerIds = 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
 
J

Jeroen Mostert

Have you ever wanted a list of customer IDs, but had to get a list of
Customers first?
Click to expand...
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<Customer> customers = getCustomers();
List<Customer> listOfCustomers = new List<Customer>(customers);
List<int> customerIds = listOfCustomers.ConvertAll<int>(delegate
(Customer current)
{
return current.ID;
});
Click to expand...
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 said:
listOfCustomers seems dirty to me. I mean, I could make that one line
of code, but then readibility suffers.
Click to expand...
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<int> customerIds = new
List<Customer>(getCustomers()).ConvertAll<int>(delegate (Customer current) {
return current.ID; })));

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

Israel

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
Click to expand...

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.
 
J

Jeroen Mostert

Israel said:
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.
Click to expand...
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 said:
Two points: Visual Studio has excellent support for debugging compound
expressions (press F9 in the right spot and you're good to go)
Click to expand...

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.
 
I

Israel

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.
Click to expand...

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<Customer> customers = getCustomers();
List<Customer> listOfCustomers = new List<Customer>(customers);
Should be functionally equivilent to this code:
List<Customer> listOfCustomers = 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.
 
J

Jeroen Mostert

Israel said:
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<Customer> customers = getCustomers();
List<Customer> listOfCustomers = new List<Customer>(customers);
Should be functionally equivilent to this code:
List<Customer> listOfCustomers = 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.
Click to expand...
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 said:
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.
Click to expand...

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.
 
J

Jeroen Mostert

Jon said:
One quick point: there's a big difference between IEnumerable and
IEnumerator.
Click to expand...

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.
Click to expand...
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 said:
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*
Click to expand...

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.
 
Top