About best coding Style of C#

[kiplring]

1.
int[] intArr = new int[255];

2.
int[] intArr = new int[255];
rgnNumberArr.Initialize();

3.
int[] intArr = new int[255];
for( int i=0; i<intArr .lenght; i++)
{
intArr = 0;
}

intArr allways initilized with 0 value?
or should I initialize it?

choose best code 1,2,3?

 

[Giulio Petrucci]

kiplring ha scritto:

1.
int[] intArr = new int[255];

2.
int[] intArr = new int[255];
rgnNumberArr.Initialize();

3.
int[] intArr = new int[255];
for( int i=0; i<intArr .lenght; i++)
{
intArr = 0;
}

intArr allways initilized with 0 value?
or should I initialize it?

choose best code 1,2,3?

uhm... I'm not what you can say a "good developer" but I should do like
this:

int intArrayLength = 255;
int[] intArr = new int[255];
for( int i=0; i<intArr .lenght; i++)
{
intArr = 0;
}


bye,
Giulio - Italia

 

[Lau Lei Cheong]

I'm not a "good developer" either, but I'll vote for no.3.

Note that the MSDN documentation explicitly stated that "if the value type
does not have a default constructor, the Array is not modified.", so no.2 is
no better than no.1.

btw, I somehow remember I've read that the .NET framework will preinitialize
interger array to zero for you but you should never rely on this
behaviour... I'm not so sure about this...

 

[Barry Kelly]

1.
int[] intArr = new int[255];

All dynamic allocation with 'new' is initialized to whatever '0' means
for that type. For this array, that means the whole array will be zeroed
out.

2.
int[] intArr = new int[255];
rgnNumberArr.Initialize();

I don't know what rgnNumberArr has to do with intArr, so I can't comment
on this code.

Array.Initialize() is for value types that have constructors (i.e. from
C++); you typically don't need to call it in a C# application. Also, the
C++ folks have been toning down their guarantees on .NET about default
construction of value types, so now it's even less necessary.

3.
int[] intArr = new int[255];
for( int i=0; i<intArr .lenght; i++)
{
intArr = 0;
}

This loop is redundant.

-- Barry

 

[Alun Harford]

1.
int[] intArr = new int[255];

2.
int[] intArr = new int[255];
rgnNumberArr.Initialize();

3.
int[] intArr = new int[255];
for( int i=0; i<intArr .lenght; i++)
{
intArr = 0;
}

If you get an int[] by calling new, you'll get an array full of 0s.
If you do it from unmanaged code, you'll get whatever junk was in that
memory before.

Alun Harford

 

[Ignacio Machin \( .NET/ C# MVP \)]

Hi,

1.
int[] intArr = new int[255];

The way to go !

2.
int[] intArr = new int[255];
rgnNumberArr.Initialize();

What is rgnNumberArr ?
In anyway calling Initialize is not needed, see what MSDN says about it:

This method is designed to help compilers support value-type arrays; most
users do not need this method. It must not be used on reference-type arrays.

If the Array is not a value-type Array or if the value type does not have a
default constructor, the Array is not modified.

The value-type Array can have any lower bound and any number of dimensions.

CAUTION You can use this method only on value types that have
constructors; however, value types that are native to C# do not have
constructors.

3.
int[] intArr = new int[255];
for( int i=0; i<intArr .lenght; i++)
{
intArr = 0;
}

Not needed, it will be done for you.

 

[Ignacio Machin \( .NET/ C# MVP \)]

Hi,

int intArrayLength = 255;
int[] intArr = new int[255];
for( int i=0; i<intArr .lenght; i++)
{
intArr = 0;
}

You do not need to initialize a value type array, it will ALWAYS have a
value (contrary to what happen with a reference typed array which will be
null ), this is why a DateTime cannot be null.

 

[Andy]

btw, I somehow remember I've read that the .NET framework will preinitialize

interger array to zero for you but you should never rely on this
behaviour... I'm not so sure about this...

You CAN rely on ints being initialized to 0; .Net guarentees that this
will happen.

 

[Mark Wilden]

1.
int[] intArr = new int[255];

2.
int[] intArr = new int[255];
rgnNumberArr.Initialize();

3.
int[] intArr = new int[255];
for( int i=0; i<intArr .lenght; i++)
{
intArr = 0;
}

intArr allways initilized with 0 value?
or should I initialize it?

I think the best way to solve this problem is 1) Look up Array.Initialize()
to see what it does, and 2) Run the code to see what it produces. Much
quicker than asking people.

///ark

 

[Jon Skeet [C# MVP]]

btw, I somehow remember I've read that the .NET framework will preinitialize
interger array to zero for you but you should never rely on this
behaviour... I'm not so sure about this...

Why would you "never rely on this behaviour"? Which other pieces of
behaviour which are documented in the language specification should you
not rely on?

 

[Jon Skeet [C# MVP]]

1.
int[] intArr = new int[255];

2.
int[] intArr = new int[255];
rgnNumberArr.Initialize();

3.
int[] intArr = new int[255];
for( int i=0; i<intArr .lenght; i++)
{
intArr = 0;
}

intArr allways initilized with 0 value?
or should I initialize it?

I think the best way to solve this problem is 1) Look up Array.Initialize()
to see what it does, and 2) Run the code to see what it produces. Much
quicker than asking people.

Running the code doesn't actually give any guarantee, however. For
instance, if the language specification didn't say what the result of
version 1 was, it might be fine at the moment but produce bogus results
later on.

Looking up array initialization in the spec is the way forward - in
this case, it *does* specify that the new array is filled with 0s to
start with.

 

[Mark Wilden]

Running the code doesn't actually give any guarantee, however. For
instance, if the language specification didn't say what the result of
version 1 was, it might be fine at the moment but produce bogus results
later on.

You're right, but for all practical purposes, running the code would give
you a quicker answer than posting to a newsgroup. It certainly should be
done just to see what the current behavior of the compiler is. As for
guarantees, there are others than are found in language standards - such as
Microsoft's desire not to break code which (fairly or unfairly) relies on
this behavior.

I was really just commenting on the practice of asking questions when a
better way is to do some experimentation, hit F1 in VS, or (indeed) look up
the issue in the spec. It always makes me think the questioner is trying to
short-circuit an interview question or homework assignment.

But you're right -- the -best- way to solve the problem is neither of the
methods I suggested.

///ark

 

[Mark Wilden]

Why would you "never rely on this behaviour"? Which other pieces of
behaviour which are documented in the language specification should you
not rely on?

I hear that. It's like initializing members to null, "just to be on the safe
side."

///ark

 

[Andy]

Running the code doesn't actually give any guarantee, however. For

instance, if the language specification didn't say what the result of
version 1 was, it might be fine at the moment but produce bogus results
later on.

The language speification DOES say what the result of #1 is; all ints
are initialized to 0. Check the CLS specification if you don't believe
me, but it does state that all number primitives MUST default to 0.

Andy

 

[Giulio Petrucci]

Ignacio Machin ( .NET/ C# MVP ) ha scritto:

Hi,

int intArrayLength = 255;
int[] intArr = new int[255];
for( int i=0; i<intArr .lenght; i++)
{
intArr = 0;
}

You do not need to initialize a value type array, it will ALWAYS have a
value (contrary to what happen with a reference typed array which will be
null ), this is why a DateTime cannot be null.

I know, but I was thinking: "ok, and if tomorrow I have to change my array
length and/or change the initial values?".

Bye,
Giulio

 

[Jon Skeet [C# MVP]]

The language speification DOES say what the result of #1 is; all ints
are initialized to 0. Check the CLS specification if you don't believe
me, but it does state that all number primitives MUST default to 0.

That's why I wrote "*if* the language specification didn't say". I then
went on to write this bit which you snipped:

<quote>
Looking up array initialization in the spec is the way forward - in
this case, it *does* specify that the new array is filled with 0s to
start with.
</quote>

 

[kiplring]

Thanks.

Whenever the framework being bigger, the developer should memorize more
rules.

I determined NO 1 choice.

 

[Andy]

Ahh, sorry Jon, it was late, and I read too fast, and missed the word
if. Sorry about that.

 

[Jon Skeet [C# MVP]]

int intArrayLength = 255;
int[] intArr = new int[255];
for( int i=0; i<intArr .lenght; i++)
{
intArr = 0;
}

You do not need to initialize a value type array, it will ALWAYS have a
value (contrary to what happen with a reference typed array which will be
null ), this is why a DateTime cannot be null.

I know, but I was thinking: "ok, and if tomorrow I have to change my array
length and/or change the initial values?".

Then tomorrow you make that change. (And tomorrow you might *use* your
intArrayLength variable There's no point in including code which
does nothing useful just in *case* you need to change it in a way
you've predicted - it's more likely that you'll need to change it in a
way which you can't predict at this point.

Google for YAGNI for more on this

 

[Lau Lei Cheong]

I won't rely on behaviours that I'm not sure at the time I write something.

I search the MSDN library, but can't find anywhere explicitly say this. The
Array Overview said nothing about it too. And everywhere here and there
inside it declares variable like this:

Copied from "Properties overview" :
ms-help://MS.MSDNQTR.2006JAN.1033/cpguide/html/cpconPropertiesOverview.htm

[C#]
private int number = 0;
[Visual Basic]
Private number As Integer = 0

So I think there should be a reason for initializing the variables
explicitly.

P.S.: I AM sure now.