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:

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.

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

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.

>I would not declare a temporary for "customers". There's no point to havingthis 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.

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

Unless there are significant performance issues (i.e. ones that a usercould possibly notice) then I opt to make as many intermediatevariables as possible just for debugging purposes. Nothing annoys memore than debugging code like:

return SomeMethod( AnotherMethod( SomeObject.Property) );

And I want to see some intermediate variables. With a sufficientlycomplex code base and various virtual method calls this style can getyou lost real quick and make you forgot what you were actuallydebugging.

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.

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.

>Two points: Visual Studio has excellent support for debugging compoundexpressions (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 anintermediary can be worse than useless, since enumerating it can change itsstate 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.

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.

>My point was that evaluating an IEnumerable changes its state. If theIEnumerable doesn't provide a usable .Reset() method (and many don't), thenyou can't continue debugging the code. That's not particularly convenient.If getCustomers() is safe to call more than once, you can reinitialize thevariable, 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.

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.