Declaring variables in the middle of your code.

[CR]

I've noticed that the trend these days is to declare variables in the
middle of code instead of at the top. What is the advantage of this?
It seems like it makes it hard to reuse variables.

Here is how all the examples I've seen so far create an OleDbCommand
Object:

Dim cmd as new OleDbCommand("S elect * FROM Table1",cnn)

I had to figure out that it was the same as this:

Dim cmd as new OleDbCommand
cmd.CommandText = "SELECT * FROM Table1"
cmd.Connection = cnn

I know it takes 3 lines but at least I know how to reuse it later. How
to you reuse the variable in the first example? I know you could do
this:

'first use
Dim cmd as new OleDbCommand("S elect * FROM Table1",cnn)

'second use
cmd.CommandText = "SELECT * FROM Table2"
cmd.Connection = cnn2

But that seems inconsistent, plus I have to figure out which
properties were which in the declaration (CommandText and Connection).

I know I'm being picky but this is bugging me! I'm old school. Or
maybe just old!

Chuck.

[Rob Teixeira [MVP]]

"CR" <cr***@hotmail. com> wrote in message
news:1a******** *************** ***@posting.goo gle.com...

P.S. Something just occured to me. Wasn't implicit instantiation (my
2nd example) discouraged in VB6? It seems I remember that anytime
"weirdness" started happening the first recommendation was to
explicitly instantiate your objects.

Yes, it was discouraged in VB6 because VB6 didn't actually create the
instance at that location. It deferred creation until you actually *used*
the class, which bloated your code with extra null checks.
However, this is no longer the case in VB.NET. The compiler does pretty much
what it looks like it should be doing now.

-Rob Teixeira [MVP]

[CR]

"Jay B. Harlow [MVP - Outlook]" <Ja************ @msn.com> wrote in message news:<Om******* *******@TK2MSFT NGP11.phx.gbl>. ..

It seems to me you have an awful lot of duplicate code in both examples!
Which is a HUGE smell in Refactoring! (http://www.refactoring.com)

In addition to Cor's suggestion of using DataSource (which is normally what
I do).

I would move the code to create & populate into its own subroutine. If I was
using the DataSet & DataSource I would look a single DataSet object with
multiple DataTables (not shown). If I could not use the DataSource as Cor
pointed out I would use a DataReader rather then creating a DataSet &
"throwing it away".

I hate to argue with someone who is helping me but I can't help it :).
When I first started working as a programmer (15 years ago), I was all
about subroutining the hell out of everything. I had been taught that
if it was more than a page it should be a function. The problem I
found with too many subs is the maintenance. The biggest problem is
you have to pass all your vars from sub to sub. It gets ugly if you
start using subs inside of subs. I was at my first job for 11 years
and 50% of what I did was maintain old code. Whenever I came across
stuff with a bunch of subs I got depressed! It's so hard to debug.
There are many cases that really need to be subbed but I would never
write a sub to fill in a listbox.

I have a question about the DataSource. I've never used it in the
earlier versions because I didn't think it was flexible. What if I
wanted to hyphenate every other entry in a listbox (for whatever
reason)?

For example how would I do this with the DataSource?

lngCount = 0
For Each dr In ds.Tables(0).Ro ws
strTemp = dr.Item("Field1 ")
if (lngCount Mod 2 = 0) then
strTemp = Left(strTemp,2) & "-" & Mid(strTemp,3)
listbox.Items.A dd(strTemp)
else
listbox.Items.A dd(strTemp)
endif
lngCount = lngCount+1
Next

Thanks!

Chuck.

[Rob Nicholson]

> middle of code instead of at the top. What is the advantage of this?

It seems like it makes it hard to reuse variables.

a) More readable as the declaration of the variable occurs next to where
it's first used so you don't have to scroll up to the top.
b) You can initialise and declare at the same time in VB.NET so why not
always declare where variable first used
c) Faster typing as you don't have to move up to the top, enter declaration
and move back down :-)

Rob

[Jay B. Harlow [MVP - Outlook]]

CR,

I hate to argue with someone who is helping me but I can't help it :). Is this an argument, a debate or a discussion. I figure its a discussion!

Also I have images of the "exact" programs that you are referring to!!

I've actually seen both! Poorly written code that uses a lot of subroutines
and poorly written code that does not use any subroutines. Just goes to show
Poor code is Poor code, despite the paradigm one chooses to use! :-) Of
course what you or I consider poor code may be the rest of the teams gold
code...

I do find that if you start really doing OOP smaller light weight objects
with smaller subroutines are far more flexible then a single monolithic
Module with a single monolithic sub-routine (yes an extreme, but I've seen
major programs written in a monolithic manner). Which is why I find
Refactoring
http://www.refactoring.com so useful. IMHO it helps to get the "right size"
of subroutine & object, especially after the subroutine/object is finished
and you need to come in later & modify it...
I have a question about the DataSource. I've never used it in the
earlier versions because I didn't think it was flexible. What do you mean "earlier versions"? DataSource is new with VB.NET 2002, it
is a extremely simple & flexible way of populating "list" controls.
What if I
wanted to hyphenate every other entry in a listbox (for whatever
reason)? Realistically often you do you need that? It seems more the exception then
the norm...
For example how would I do this with the DataSource?
I would populate the DataTable or "domain" collection with hyphenated rows,
especially if the "list" is used in more then one place. Otherwise I would
consider simply using a DataReader and building the list similar to your
code.

The point Cor & I are attempting to make about the DataSource, is we would
NOT populate a DataTable (DataSet) simply to iterate over it to populate
Items collection, if I populated the DataSet I would use the DataSource, if
I needed to populate just the ITems collection (for hyphenation for example)
I would use a DataReader... (sample of DataReader given in early post). As
the DataSource property can be used in the designer and produces very
compact code.

Hope this helps
Jay

"CR" <cr***@hotmail. com> wrote in message
news:1a******** *************** ***@posting.goo gle.com... "Jay B. Harlow [MVP - Outlook]" <Ja************ @msn.com> wrote in message news:<Om******* *******@TK2MSFT NGP11.phx.gbl>. ..

It seems to me you have an awful lot of duplicate code in both examples!
Which is a HUGE smell in Refactoring! (http://www.refactoring.com)

In addition to Cor's suggestion of using DataSource (which is normally what I do).

I would move the code to create & populate into its own subroutine. If I was using the DataSet & DataSource I would look a single DataSet object with
multiple DataTables (not shown). If I could not use the DataSource as Cor pointed out I would use a DataReader rather then creating a DataSet &
"throwing it away".

I hate to argue with someone who is helping me but I can't help it :).
When I first started working as a programmer (15 years ago), I was all
about subroutining the hell out of everything. I had been taught that
if it was more than a page it should be a function. The problem I
found with too many subs is the maintenance. The biggest problem is
you have to pass all your vars from sub to sub. It gets ugly if you
start using subs inside of subs. I was at my first job for 11 years
and 50% of what I did was maintain old code. Whenever I came across
stuff with a bunch of subs I got depressed! It's so hard to debug.
There are many cases that really need to be subbed but I would never
write a sub to fill in a listbox.

I have a question about the DataSource. I've never used it in the
earlier versions because I didn't think it was flexible. What if I
wanted to hyphenate every other entry in a listbox (for whatever
reason)?

For example how would I do this with the DataSource?

lngCount = 0
For Each dr In ds.Tables(0).Ro ws
strTemp = dr.Item("Field1 ")
if (lngCount Mod 2 = 0) then
strTemp = Left(strTemp,2) & "-" & Mid(strTemp,3)
listbox.Items.A dd(strTemp)
else
listbox.Items.A dd(strTemp)
endif
lngCount = lngCount+1
Next

Thanks!

Chuck.

[CR]

"Jay B. Harlow [MVP - Outlook]" <Ja************ @msn.com> wrote in message news:<u$******* *******@TK2MSFT NGP11.phx.gbl>. ..

CR,

I hate to argue with someone who is helping me but I can't help it :). Is this an argument, a debate or a discussion. I figure its a discussion!

Also I have images of the "exact" programs that you are referring to!!

I've actually seen both! Poorly written code that uses a lot of subroutines
and poorly written code that does not use any subroutines. Just goes to show
Poor code is Poor code, despite the paradigm one chooses to use! :-) Of
course what you or I consider poor code may be the rest of the teams gold
code...

Now that I think about it I use Fill_ListBox subroutines constantly
(oops!). Usually when there's a situation when I want to fill the
ListBox during the Form_Load event and later when the user clicks on a
button. Forget about what I said about never using it. I think the
most important reason to make a sub is for it to be reusable. If
you're just doing it to make your routine shorter, that's a bad
reason.

I have a question about the DataSource. I've never used it in the
earlier versions because I didn't think it was flexible.

What do you mean "earlier versions"? DataSource is new with VB.NET 2002, it
is a extremely simple & flexible way of populating "list" controls.

Didn't they have something called a DataControl in VB6? I just assumed
that was the same type of thing.

What if I
wanted to hyphenate every other entry in a listbox (for whatever
reason)?

Realistically often you do you need that? It seems more the exception then
the norm...

I think it's fairly common for me to modify the data somewhat before I
display in a listbox. The hyphenated example was a bit extreme, but
the idea is that I don't always display data straight out of the
database. I'll have to give the DataSource a try, however. I didn't
know you could use it with straight code, I can't stand using wizards.
The point Cor & I are attempting to make about the DataSource, is we would
NOT populate a DataTable (DataSet) simply to iterate over it to populate
Items collection, if I populated the DataSet I would use the DataSource, if
I needed to populate just the ITems collection (for hyphenation for example)
I would use a DataReader... (sample of DataReader given in early post). As
the DataSource property can be used in the designer and produces very
compact code.

My goal is to be able to use the same method, even if it's
inefficient. For example when filling a listbox I don't want to fill
it using the DataSource one time and then ListBox.Items.A dd another
time. Same thing with the Datareader vs the DataSet. I'd prefer to use
the DataSet all the time, even if it would be more efficient to use
the DataReader. My programs are fast enough that I don't worry about
speed, I just want them to be easy to maintain.

Thanks!

Chuck.

[Jay B. Harlow [MVP - Outlook]]

CR

Didn't they have something called a DataControl in VB6? I just assumed
that was the same type of thing. Same type of thing, IMHO significantly better implementation! (I've seen
others say the same thing).
I think it's fairly common for me to modify the data somewhat before I
display in a listbox. The hyphenated example was a bit extreme, but
the idea is that I don't always display data straight out of the
database. I'll have to give the DataSource a try, however. I didn't
know you could use it with straight code, I can't stand using wizards. Remember you can put "computed" columns in a DataTable, so you can message
the data to a certain degree without an "exterior" loop.
My goal is to be able to use the same method, even if it's
inefficient. For example when filling a listbox I don't want to fill
it using the DataSource one time and then ListBox.Items.A dd another Understood, on a project by project basis I do that.

If you don't have it and I have not mentioned it, you may want to consider
getting David Sceppa's book "Microsoft ADO.NET - Core Reference" from MS
Press it is a very good tutorial (on a number of topics we touched on in
this thread) as well as a good desk reference once your using ADO.NET.

Hope this helps
Jay

"CR" <cr***@hotmail. com> wrote in message
news:1a******** *************** ***@posting.goo gle.com... "Jay B. Harlow [MVP - Outlook]" <Ja************ @msn.com> wrote in message

news:<u$******* *******@TK2MSFT NGP11.phx.gbl>. ..

CR,

I hate to argue with someone who is helping me but I can't help it :).

Is this an argument, a debate or a discussion. I figure its a discussion!

Also I have images of the "exact" programs that you are referring to!!

I've actually seen both! Poorly written code that uses a lot of subroutines and poorly written code that does not use any subroutines. Just goes to show Poor code is Poor code, despite the paradigm one chooses to use! :-) Of
course what you or I consider poor code may be the rest of the teams gold code...

Now that I think about it I use Fill_ListBox subroutines constantly
(oops!). Usually when there's a situation when I want to fill the
ListBox during the Form_Load event and later when the user clicks on a
button. Forget about what I said about never using it. I think the
most important reason to make a sub is for it to be reusable. If
you're just doing it to make your routine shorter, that's a bad
reason.
I have a question about the DataSource. I've never used it in the
earlier versions because I didn't think it was flexible.

What do you mean "earlier versions"? DataSource is new with VB.NET 2002, it

is a extremely simple & flexible way of populating "list" controls.

Didn't they have something called a DataControl in VB6? I just assumed
that was the same type of thing.
What if I
wanted to hyphenate every other entry in a listbox (for whatever
reason)?

Realistically often you do you need that? It seems more the exception then the norm...

I think it's fairly common for me to modify the data somewhat before I
display in a listbox. The hyphenated example was a bit extreme, but
the idea is that I don't always display data straight out of the
database. I'll have to give the DataSource a try, however. I didn't
know you could use it with straight code, I can't stand using wizards.

The point Cor & I are attempting to make about the DataSource, is we would NOT populate a DataTable (DataSet) simply to iterate over it to populate
Items collection, if I populated the DataSet I would use the DataSource, if I needed to populate just the ITems collection (for hyphenation for example) I would use a DataReader... (sample of DataReader given in early post). As the DataSource property can be used in the designer and produces very
compact code.

My goal is to be able to use the same method, even if it's
inefficient. For example when filling a listbox I don't want to fill
it using the DataSource one time and then ListBox.Items.A dd another
time. Same thing with the Datareader vs the DataSet. I'd prefer to use
the DataSet all the time, even if it would be more efficient to use
the DataReader. My programs are fast enough that I don't worry about
speed, I just want them to be easy to maintain.

Thanks!

Chuck.