Thoughts on "var" usage

[Chrisa23]

I am following closely and also willing to contribute.

In looking through the code I am noticing one thing that is really a
pet peeve of mine and I think a very bad practice. The overuse of
"var".

var nextSequence = Sequence + 1; <<< BAD

Code like this is completely confusing. I don't think var should be
used without the type being explicitly listed on the line elsewhere,
as in a "new" or "as". I never use it with value types.

var lifecycleAware = _handler as ILifecycleAware; <<GOOD

I tend to think Resharper's default handling of "var" in CodeCleanup
is ideal, unless they changed it.

Anyone else have thoughts on this?

Chris

[Olivier]

Hi Chris,

I agree, I overuse "var" and it makes sense to use explicit
declaration, especially for value types.

I'm happy to use Code Cleanup default handling.

Olivier

[Olivier]

I remove part of what I just said...

I just tried using default code cleanup and now I remember why I was
no longer using it:
- add useless regions everywhere
- does not use var enough, for instance:

IReferenceTypeForceFillProducerBarrier<StubData>
forceFillProducerBarrier =
_ringBuffer.CreateForceFillProducerBarrier(new
NoOpConsumer<StubData>(_ringBuffer));

compared to

var forceFillProducerBarrier =
_ringBuffer.CreateForceFillProducerBarrier(new
NoOpConsumer<StubData>(_ringBuffer)); <<< GOOD

bool producerComplete = false; <<< BAD

Task<List<StubData>> task = Task.Factory.StartNew(() =>
testWaiter.Call()); <<< Too much noise

I hated var when it was released first but after a couple of years of
RX I'm not sure I can live without it, there is far too much noise in
the code when you don't use it (except maybe sometime for value
types).

My 2p

Olivier

[Chrisa23]

I only meant default "var" usage. I have my own custom code cleanup
settings I use and I hate regions. I use CodeCleanup all the time and
its one of the only things I always set up to my liking in a new
Resharper install.

I disagree on the bool one... I think that should still be bool...

I see your point on the long winded ones with factory methods. Those
are always edge cases... I would question whether
IReferenceTypeForceFillProducerBarrier is a bit long winded though in
its name. I understand the need to differentiate, but it is six words
with 3 over 7 letters... 38 letters total on quick count...

I disagree on the Task one as well. I see your point, but for
readability and developer usability you should not have to mouse over
a type to understand what it is. If I am just reading the code
outside an IDE, it is the opposite of helpful.

Chris