About best coding Style of C#

[kiplring]

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

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

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

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

choose best code 1,2,3?

[Lau Lei Cheong]

While I'm reading readings on YAGNI, I have a feeling that YAGNI isn't good
for all cases, especially when you foresee there will be a change breaking
"fundamenta l assumptions" when you design the application. In that case you
will really curse yourself for not writing "not currently needed code" in
the very beginning.

I have a project in hand that because the origional writer does not foresee
there will be other completely different types of products (yes, the
origional code does handle a range of products, but they all have common
characteristics , so the "alien types" added later cased huge trouble), he
ends up need to rewrite nearly half of the application just for that. If he
had the idea that "there might be other type of products that have
completely different characteritics" , he'd write more flexible code and
suffer less when the new type is added.

"Jon Skeet [C# MVP]" <sk***@pobox.co m>
???????:MP***** *************** ****@msnews.mic rosoft.com...

Giulio Petrucci <gi************ *@RIMUOVIspeech village.com> wrote:
Google for YAGNI for more on this :)

[Mark Wilden]

"Lau Lei Cheong" <le****@yehoo.c om.hk> wrote in message
news:%2******** ********@TK2MSF TNGP03.phx.gbl. ..

While I'm reading readings on YAGNI, I have a feeling that YAGNI isn't
good for all cases, especially when you foresee there will be a change
breaking "fundamenta l assumptions" when you design the application.
If you can accurately foresee such changes, then Y-Are-GNI. If not, you
should just make sure you follow normal OOP principles, and then you'll be
prepared to change the design when and as needed.
In that case you will really curse yourself for not writing "not currently
needed code" in the very beginning.
The problem is in knowing what code will be needed. If you do spend
significant time handling nonexistent requirements, you may never get a
chance to see if those requirements are ever introduced, because your
project doesn't ship in time and your company runs out of money!
I have a project in hand that because the origional writer does not
foresee there will be other completely different types of products (yes,
the origional code does handle a range of products, but they all have
common characteristics , so the "alien types" added later cased huge
trouble), he ends up need to rewrite nearly half of the application just
for that.
Well, there's bad code of all flavors. And a design that required rewriting
half the application when it changed was never a good design.

But should you really design for "completely different types of products"
when there is absolutely no indication that you'll ever need that
capability? If you're selling insurance policies, should you design it so
you can also sell bicycle tires? It's going to take longer if you do design
it for bicycle tires, and cost more. And you may go out of business while
you're doing it.
If he had the idea that "there might be other type of products that have
completely different characteritics" , he'd write more flexible code and
suffer less when the new type is added.

Predicting the future is hard, and we always look bad when we guess wrong.
That's why YAGNI says not to worry about the future. Changing software to
meet changing requirements when necessary should not be hard, because those
requirements certainly will change. The trick is to write good, separated,
encapsulated, seamful (polymorphic) code that can be changed with a minimum
of bother, not code that can handle unrequired requirements.

(Jon will no doubt address this much better than me, and I'm looking forward
to his reply.)

///ark

[Jon Skeet [C# MVP]]

Mark Wilden <Ma********@new sgroups.nospam> wrote:

<snip>

(Jon will no doubt address this much better than me, and I'm looking forward
to his reply.)

Sorry to disappoint, but I think you said it all better than I could
have done anyway :)

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[Jon Skeet [C# MVP]]

Lau Lei Cheong <le****@yehoo.c om.hk> wrote:

I won't rely on behaviours that I'm not sure at the time I write something.
That's reasonable - but it's also reasonable *to* rely on behaviour
when it's specified. (The way you phrased it originally suggested that
even when it's documented you shouldn't rely on it.)
I search the MSDN library, but can't find anywhere explicitly say this. The
Array Overview said nothing about it too.
Indeed - it's in the C# language spec in this case.
And everywhere here and there
inside it declares variable like this:

Copied from "Properties overview" :
ms-help://MS.MSDNQTR.2006 JAN.1033/cpguide/html/cpconProperties Overview.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.

There's plenty of bad code in MSDN - and initialising a single variable
to its default value isn't actually so bad anyway. Going through and
initialising a whole array suggests that something useful is happening
when it isn't.

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[Lau Lei Cheong]

One OT(since it's a C# newsgroup) question - Given it's a C# specification
behaviour, would I be safe to assume that it'd be the same in VB.NET?

"Jon Skeet [C# MVP]" <sk***@pobox.co m>
???????:MP***** *************** ****@msnews.mic rosoft.com...

Indeed - it's in the C# language spec in this case.

[Jon Skeet [C# MVP]]

Lau Lei Cheong wrote:

One OT(since it's a C# newsgroup) question - Given it's a C# specification
behaviour, would I be safe to assume that it'd be the same in VB.NET?

Not necessarily. In fact, I *believe* it's also specified in the CLI,
although a quick flick through doesn't make it obvious, unless this is
covered in 8.9.6.6 or partition 1, which says that user-visible memory
for a new value of an object type is zeroed.

It would be best to check in the VB.NET specification - although I'd be
very surprised if it weren't the same.

Jon

[Sericinus hunter]

Jon Skeet [C# MVP] wrote:
....

There's plenty of bad code in MSDN - and initialising a single variable
to its default value isn't actually so bad anyway.

Except there are more instructions generated in IL, while the default
initialization is performed some other way.
Another thing looks strange. We know now that explicit initialization
to default value is redundant and just plain wrong because efficiency
suffers. This is documented and supposed to be followed, at least at MS.
Then, why compiler does not allow me do things like this:
int i;
int ii = i;
throwing "using unassigned variable" error?

[Mark Wilden]

"Sericinus hunter" <se*****@flash. net> wrote in message
news:cz******** ************@ne wssvr21.news.pr odigy.com...

Another thing looks strange. We know now that explicit initialization
to default value is redundant and just plain wrong because efficiency
suffers.
To me, initialization of fields to default values just screams "the writer
doesn't know C#!"

I'm glad to have another reason besides snobbery to deprecate it.
This is documented and supposed to be followed, at least at MS.
Then, why compiler does not allow me do things like this:
int i;
int ii = i;
throwing "using unassigned variable" error?

(I assume you're talking about fields, not local variables - in the latter
case, i is not initialized.)

True, but you can't do

int i = 0;
int ii = i + 1;

either. For whatever reason, field initializers aren't allowed to access
nonstatic fields.

///ark

[Sericinus hunter]

Mark Wilden wrote:

"Sericinus hunter" <se*****@flash. net> wrote in message
news:cz******** ************@ne wssvr21.news.pr odigy.com...

Another thing looks strange. We know now that explicit initialization
to default value is redundant and just plain wrong because efficiency
suffers.

To me, initialization of fields to default values just screams "the writer
doesn't know C#!"

I'm glad to have another reason besides snobbery to deprecate it.

This is documented and supposed to be followed, at least at MS.
Then, why compiler does not allow me do things like this:
int i;
int ii = i;
throwing "using unassigned variable" error?

(I assume you're talking about fields, not local variables - in the latter
case, i is not initialized.)

Sorry, I just jumped a step ahead without warning... We discussed
specification for field initialization, but I am talking about local
variables now. Looks like it is initialized. If I write:

int i;
i = 1;

and stop in the debugger right after its declaration, I can see it having value 0.
And the message is quite clear on that: it says "unassigned ". It is probably
due to the language spec vs CLI spec, and designed so just to be safer.

[Ian Semmel]

Mark Wilden wrote:

"Sericinus hunter" <se*****@flash. net> wrote in message
news:cz******** ************@ne wssvr21.news.pr odigy.com...

Another thing looks strange. We know now that explicit initialization
to default value is redundant and just plain wrong because efficiency
suffers.

To me, initialization of fields to default values just screams "the writer
doesn't know C#!"

It doesn't mean any such thing. It means that the coder has a variable that
he/she wants initialized to 0.