Are these two identical

[Tony]

Hello!

Here I have two different ways to create an array of DataRowView. In this
example is it really any reason to use alternative 2 because the first is
much shorter ?

1. DataRowView[] rows = new DataRowView[dv.Count];
2. DataRowView[] rows = (DataRowView[])
Array.CreateInstance(typeof(DataRowView), dv.Count);

//Tony

 

[Arne Vajhøj]

Here I have two different ways to create an array of DataRowView. In
this example is it really any reason to use alternative 2 because the
first is much shorter ?

1. DataRowView[] rows = new DataRowView[dv.Count];
2. DataRowView[] rows = (DataRowView[])
Array.CreateInstance(typeof(DataRowView), dv.Count);

As the code is written then you can just use #1.

Array.CreateInstance makes sense for code like:

public void Foo(Type typ, int nelem)
{
Bar(Array.CreateInstance(typ, nelm));
}

where you first know the type at runtime.

Arne

 

[Tony]

Here I have two different ways to create an array of DataRowView. In
this example is it really any reason to use alternative 2 because the
first is much shorter ?

1. DataRowView[] rows = new DataRowView[dv.Count];
2. DataRowView[] rows = (DataRowView[])
Array.CreateInstance(typeof(DataRowView), dv.Count);

As the code is written then you can just use #1.

Array.CreateInstance makes sense for code like:

public void Foo(Type typ, int nelem)
{
Bar(Array.CreateInstance(typ, nelm));
}

where you first know the type at runtime.

Arne

You say "As the code is written then you can just use #1."
But in fact I can use both 1 or 2 they get the same result.

//Tony


//Tony

 

[Marcel Müller]

You say "As the code is written then you can just use #1."
But in fact I can use both 1 or 2 they get the same result.

#2 uses reflection, i.e less compile time type safety and significantly
slower. Once the array is created an cast to the appropriate type, it
makes no more difference.


Marcel

 

[Arne Vajhøj]

Here I have two different ways to create an array of DataRowView. In
this example is it really any reason to use alternative 2 because the
first is much shorter ?

1. DataRowView[] rows = new DataRowView[dv.Count];
2. DataRowView[] rows = (DataRowView[])
Array.CreateInstance(typeof(DataRowView), dv.Count);

As the code is written then you can just use #1.

Array.CreateInstance makes sense for code like:

public void Foo(Type typ, int nelem)
{
Bar(Array.CreateInstance(typ, nelm));
}

where you first know the type at runtime.

You say "As the code is written then you can just use #1."
But in fact I can use both 1 or 2 they get the same result.

You can use both, but you have no reason to use the more
complex #2.

Arne

 

[Kris Sheglova]

Hi Tony,

Use #1, Array.CreateInstance is for specific applications as Arne
suggests. Let the compiler do the work for you.
You can make it even shorter if you want and save yourself some
typing:

var rows = new DataRowView[dv.Count];

Kris Sheglova

 

[Arne Vajhøj]

Use #1, Array.CreateInstance is for specific applications as Arne
suggests. Let the compiler do the work for you.
You can make it even shorter if you want and save yourself some
typing:

var rows = new DataRowView[dv.Count];

It saves typing today.

But it may require more reading the next decade.

Arne

 

[Jeff Johnson]

Use #1, Array.CreateInstance is for specific applications as Arne
suggests. Let the compiler do the work for you.
You can make it even shorter if you want and save yourself some
typing:

var rows = new DataRowView[dv.Count];

NOOOOO!!!

This var crap must DIE! It is lazy, lazy, lazy. Use it ONLY when you don't
know what the underlying type will be (like with LINQ). Do NOT be lazy when
you know the type.

 

[Gene Wirchenko]

On Tue, 3 Jan 2012 16:53:03 -0800, Peter Duniho

[snip]

p.s. This post marks the first using a new newsreader, subsequent to my
transition back to Windows from my Mac after five years. I hope I've got
everything set up right, but apologize if the post comes through screwed up
for some reason.

Your post came through just fine.

Sincerely,

Gene Wirchenko

 

[Arne Vajhøj]

Use #1, Array.CreateInstance is for specific applications as Arne
suggests. Let the compiler do the work for you.
You can make it even shorter if you want and save yourself some
typing:

var rows = new DataRowView[dv.Count];

NOOOOO!!!

This var crap must DIE! It is lazy, lazy, lazy. Use it ONLY when you don't
know what the underlying type will be (like with LINQ). Do NOT be lazy when
you know the type.

I completely agree.

But there are a lot of .NET developers out there that are
starting to use var for everything.

So that style is not going to die.

Arne

 

[Arne Vajhøj]

Use #1, Array.CreateInstance is for specific applications as Arne
suggests. Let the compiler do the work for you.
You can make it even shorter if you want and save yourself some
typing:

var rows = new DataRowView[dv.Count];

NOOOOO!!!

This var crap must DIE! It is lazy, lazy, lazy. Use it ONLY when you don't
know what the underlying type will be (like with LINQ). Do NOT be lazy when
you know the type.

I'm definitely wary of the use of "var" outside anonymous types. However,
I wouldn't go so far as to reject its use outright in other scenarios,
including the one you're objecting to here.

IMHO, if the type of the variable is clear from context, there's little
point in redundantly stating the type in the variable declaration. For
example:

var o = new object();

The type is clearly stated, since it has to be used for the constructor.
Using "object" instead of "var" would not improve readability much, if at
all.

It would improve a bit.

Because we read from left to right.

So by having the type in front allow you to read the type by only
reading half the line instead of the full line.

On the other hand, where the type is not clear from context, I do agree it
should be explicitly given in the variable declaration, even if the
compiler can infer it. For example:

string[] args = ProcessInputFile();

The method name doesn't provide any readable type information at all. In
VS, it's easy enough to hover the mouse over the method and obtain that
information but IMHO code should be readable as-is, without assuming the
use of interpretive tools.

I agree.

But there is also an additional point.

Using var in some case and not in other cases it not consistent.

There is one other place that I use "var" even when the type is not
explicitly stated. That is when dealing with KeyValuePair<TKey, TValue>,
especially in foreach loops. For example:

Dictionary<int, string> mapping = ...;

foreach (var kvp in mapping)
{
// ...do stuff
}

I just get so sick of typing things like "KeyValuePair<int, string>", and
the Dictionary<TKey, TValue> type is commonly used enough that I don't fear
a competent programmer seeing that code and getting confused.

I know the feeling.

But it is only a psychological nuisance. The time spent on typing
is not really significant.

Arne

 

[Gene Wirchenko]

On 1/3/2012 7:53 PM, Peter Duniho wrote:
[snip]

I just get so sick of typing things like "KeyValuePair<int, string>", and
the Dictionary<TKey, TValue> type is commonly used enough that I don't fear
a competent programmer seeing that code and getting confused.

I know the feeling.

But it is only a psychological nuisance. The time spent on typing
is not really significant.

It is to me. (YMMV.) It is another opportunity to get it wrong.
I am a good touch-typist with alphabetics, but with special
characters, I am slower. It does not add value for me.

Sincerely,

Gene Wirchenko

 

[Gene Wirchenko]

On Tue, 03 Jan 2012 20:24:44 -0500, Arne Vajhøj wrote:
[snip]

So by having the type in front allow you to read the type by only
reading half the line instead of the full line.

See above. No one is going to just read "half the line" anyway, even if
they are mentally processing the line one token at a time, but for many if
not most people, they are interpreting the entire line at once anyway.

I do, and quite frequently. When looking through code for a
particular section of code or checking blocks, I often read only the
left-hand part. I expect that many do so without being aware of it.

My code formatting is such that I can take more advantage of
this.

[snip]

Sincerely,

Gene Wirchenko