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("Select * 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("Select * 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]]

It doesn't matter where you declare your local variables inside your
procedures. The compiler/runtime will set a variable declaration block for
each procedure, and this happens before any code actually runs (because in
..NET, the stack is carefully managed, and always fixed for any given member
call). This adds a level of security and is one of the things that helps
prevent buffer overruns.

However, from your example, it seems you are more interested with
Constructors. Constructors are special procedures that build class instances
(when you call New). They weren't available as such in VB4/5/6, but are
..NET. They help keep the code more compact, among other things. In certain
cases, they prevent class instances from being in an incomplete or invalid
state because the object must be initialized to correct values as soon as it
is created. Every class can define as many constructure procedures as
necessary, each with different parameters. You can only use the old style
instanciation if the class provides a constructor with no parameters (which
most do). Sometimes (but not always), using the constructor can be a tad bit
faster in execution speed than calling the individual properties. This is
not guaranteed.
Other than the cases where no Parameterless (Default) Constructor exists,
whether you use optional constructors vs. specifying one property at a time,
is basically a matter of choice.
I'm sure some people will call it old-school though

-Rob Teixeira [MVP]

 

[Jay B. Harlow [MVP - Outlook]]

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?

I find having declaration of the variable is by the code that uses it,
making it easier to see what the declaration is. Also as your example shows
it allows you to initialize the variable when you declare it.

Sometimes you can actually scope the variable to the specific statement, for
example:

' VS.NET 2003 syntax
For Each index As Integer = 0 to 9
' do something with index
Next

The 'index' variable is only valid within the For statement.

It seems like it makes it hard to reuse variables.

Reusing variables is not always a good idea!

If you set a variable at the top of your function, then use it at the bottom
of your function, then later decide to "reuse" it in the middle of your
function. Hopefully you find the problem right away, rather then 6 months
later, when a problem occurs...

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

I find your example a good example of why NOT to reuse a variable, not where
reusing it is a good idea.

I would actually define cmdTable1, cmdTable2 variables which effectively
eliminates your problem of "which properties were in the declaration"). As
you know what is in which variable, and you don't need to worry about when
is this variable this & when is it that. Further I would consider having two
routines, SelectTable1 & SelectTable2 that created & executed the
commands...

Note when I do want to reuse the variable (name) I normally do:

Dim cmd as OleDbCommand

'first use

cmd = New OleDbCommand("Select * FROM Table1",cnn)

'second use

cmd = New OleDbCommand("SELECT * FROM Table2", cnn2)

Notice I am reinitializing the variable itself as to avoid reusing the
object, which can cause problems.

Another trend I hope you are noticing is to have smaller more dedicated
functions, rather then larger more general functions.

Martin Fowler's book "Refactoring - Improving the Design of Existing Code"
by Addision Wesley http://www.refactoring.com, offers a number of 'smells'
in code and how to correct them. I don't see where he explicitly suggests to
put the declaration by the use, however it does appear that it is an
implicit practice. Also he promotes the smaller dedicated functions/object
over the larger more general function/object practice of coding.

Hope this helps
Jay

 

[Cor]

Hi CR,

A old style answer,

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.

What is 100bytes in a computer from today.
The benefit is that your variables are always new and you do not have to
test if you can use them at that moment.

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

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

In this way you can use your command a lot of times.
By instance when you are building a new table in the database

I think old school however probably young enough to change. Otherwise it
would not botter you anymore.

With VB.net you can do things as effective as you want, depending on things
as; is it often running, is it a one time program, is it etc etc.

I hope this gives an idea?

Cor

 

[CR]

However, from your example, it seems you are more interested with
Constructors. Constructors are special procedures that build class instances
(when you call New). They weren't available as such in VB4/5/6, but are
.NET. They help keep the code more compact, among other things. In certain
cases, they prevent class instances from being in an incomplete or invalid
state because the object must be initialized to correct values as soon as it
is created. Every class can define as many constructure procedures as
necessary, each with different parameters. You can only use the old style
instanciation if the class provides a constructor with no parameters (which
most do). Sometimes (but not always), using the constructor can be a tad bit
faster in execution speed than calling the individual properties. This is
not guaranteed.
Other than the cases where no Parameterless (Default) Constructor exists,
whether you use optional constructors vs. specifying one property at a time,
is basically a matter of choice.
I'm sure some people will call it old-school though

I guess I'll have to break down and do it the new way (declaring in
the middle). It does make the code more compact and I hate having to
research every example I see in a book to make it fit my old style.

Thanks!

Chuck.

 

[Charlie Smith]

(e-mail address removed) (CR) wrote in message

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.

Chuck,

In addition to the other things mentioned, it makes code easier to
read. As I get older I discover that six months later I can't
remember what I did without reading through the code to see where it
goes. This is where not haveing to scroll up and down to get the whole
picture is a big help(this stuff was a lot easier at 30 and even 40,
OK). This is also one of the reasons I enjoy .NET so much, the code
is very compact and easy to read.

Charlie

 

[CR]

(e-mail address removed) (Charlie Smith) wrote in message

Chuck,

In addition to the other things mentioned, it makes code easier to
read. As I get older I discover that six months later I can't
remember what I did without reading through the code to see where it
goes. This is where not haveing to scroll up and down to get the whole
picture is a big help(this stuff was a lot easier at 30 and even 40,
OK). This is also one of the reasons I enjoy .NET so much, the code
is very compact and easy to read.

Charlie

OK, I'm convinced! Now I'm wondering if I should go all the way with
this and declare all the variables in the middle as needed. What is
considered proper programming style?

Thanks!

 

[CR]

I would actually define cmdTable1, cmdTable2 variables which effectively
eliminates your problem of "which properties were in the declaration"). As
you know what is in which variable, and you don't need to worry about when
is this variable this & when is it that. Further I would consider having two
routines, SelectTable1 & SelectTable2 that created & executed the
commands...

OK here's 2 examples of filling ListBox1 and ListBox2 with 2 different
SQL statements.

This is putting all the declares at the top:

Dim cnn As System.Data.OleDb.OleDbConnection
Dim cmd As System.Data.OleDb.OleDbCommand
Dim da As System.Data.OleDb.OleDbDataAdapter
Dim ds As System.Data.DataSet
Dim dr As System.Data.DataRow

'open connection
cnn = New System.Data.OleDb.OleDbConnection("Provider=Microsoft.Jet.OLEDB.4.0;Data
Source=c:\test.mdb;")
cnn.Open()

'fill DataSet1
cmd = New System.Data.OleDb.OleDbCommand("Select * FROM Table1", cnn)
da = New System.Data.OleDb.OleDbDataAdapter(cmd)
ds = New System.Data.DataSet
da.Fill(ds)

'fill ListBox1
For Each dr In ds.Tables(0).Rows
ListBox1.Items.Add(dr.Item("Field1"))
Next

'fill DataSet2
cmd = New System.Data.OleDb.OleDbCommand("Select * FROM Table2", cnn)

'fill ListBox2
For Each dr In ds.Tables(0).Rows
ListBox2.Items.Add(dr.Item("Field1"))
Next

'close connection
cnn.Close()

This is using declares in the middle:

'open connection
Dim cnn As New System.Data.OleDb.OleDbConnection("Provider=Microsoft.Jet.OLEDB.4.0;Data
Source=c:\test.mdb;")
cnn.Open()

'fill DataSet1
Dim cmd1 As New System.Data.OleDb.OleDbCommand("Select * FROM Table1",
cnn)
Dim da1 As New System.Data.OleDb.OleDbDataAdapter(cmd1)
Dim ds1 As New System.Data.DataSet
da1.Fill(ds1)

'fill ListBox1
Dim dr1 As System.Data.DataRow
For Each dr1 In ds1.Tables(0).Rows
ListBox1.Items.Add(dr1.Item("Field1"))
Next

'fill DataSet2
Dim cmd2 As New System.Data.OleDb.OleDbCommand("Select * FROM Table1",
cnn)
Dim da2 As New System.Data.OleDb.OleDbDataAdapter(cmd2)
Dim ds2 As New System.Data.DataSet
da2.Fill(ds2)

'fill ListBox2
Dim dr2 As System.Data.DataRow
For Each dr2 In ds2.Tables(0).Rows
ListBox2.Items.Add(dr2.Item("Field1"))
Next

'close connection
cnn.Close()

Which method is more "by the book" in your opinion?

Thanks! You guys have really helped.

Chuck.

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. For example:

do this:

dim rst as recordset
set rst = new recordset

instead of this:

dim rst as new recordset

 

[Cor]

Hi CR

The simplest way
\\\
dim cnn as new OleDB.OledbConnection("Provider=Microsoft.Jet.OLEDB.4.0;Data
Source=c:\test.mdb;")
dim ds as new dataset
dim da as new oledb.oledbdataadapter("Select * FROM Table1", cnn)
da.fill(ds)
cnn.close
listbox1.datasource=ds.tables(0)
listbox1.displaymember="Field1"
///



Cor

 

[Jay B. Harlow [MVP - Outlook]]

CR,

Which method is more "by the book" in your opinion?

Both!

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".

'open connection
Dim cnn As New
System.Data.OleDb.OleDbConnection("Provider=Microsoft.Jet.OLEDB.4.0;Data
Source=c:\test.mdb;")
cnn.Open()

FillListBox(ListBox1, "Field1", "Select Field1 From Table1", cnn)
FillListBox(ListBox2, "Field1", "Select FIeld1 From Table2", cnn)

'close connection
cnn.Close()


' Use a DataSet
Private Shared Sub FillListBoxViaDataSet(ByVal listbox As ListBox, ByVal
columnName As String, ByVal cmtText As String, ByVal cnn As
OleDb.OleDbConnection)
'fill DataSet
Dim cmd As New System.Data.OleDb.OleDbCommand(cmtText, cnn)
Dim da As New System.Data.OleDb.OleDbDataAdapter(cmd)
Dim ds As New System.Data.DataSet
da.Fill(ds)

'fill ListBox
Dim dr As System.Data.DataRow
For Each dr In ds.Tables(0).Rows
listbox.Items.Add(dr.Item(columnName))
Next
End Sub

' Use a DataReader
Private Shared Sub FillListBox(ByVal listbox As ListBox, ByVal
columnName As String, ByVal cmdText As String, ByVal cnn As
OleDb.OleDbConnection)
Dim cmd As New System.Data.OleDb.OleDbCommand(cmdText, cnn)
Dim dr As OleDb.OleDbDataReader = cmd.ExecuteReader()
Do While dr.Read()
listbox.Items.Add(dr.Item(columnName))
Loop
End Sub

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. For example:

Yes, it was discouraged in VB6, however in .NET it is explicit instantiation
so there is no problem!

Hope this helps
Jay

 

[Rob Teixeira [MVP]]

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]

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).Rows
strTemp = dr.Item("Field1")
if (lngCount Mod 2 = 0) then
strTemp = Left(strTemp,2) & "-" & Mid(strTemp,3)
listbox.Items.Add(strTemp)
else
listbox.Items.Add(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

"Jay B. Harlow [MVP - Outlook]" <[email protected]> wrote in message

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).Rows
strTemp = dr.Item("Field1")
if (lngCount Mod 2 = 0) then
strTemp = Left(strTemp,2) & "-" & Mid(strTemp,3)
listbox.Items.Add(strTemp)
else
listbox.Items.Add(strTemp)
endif
lngCount = lngCount+1
Next

Thanks!

Chuck.

 

[CR]

CR,
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.

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.

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.Add 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.Add 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

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.

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.

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.Add 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.[/QUOTE]