FOR ALL - Best Practices for navigating within code? -plus - Add-In's that help?

[Rex]

Hi All - I have a question that I think MIGHT be of interest to a
number of us developers. I am somewhat new to VIsual Studio 2005 but
not new to VB. I am looking for ideas about quick and efficient
navigating within Visual Studio 2005. Let's say your project (or
solution) has dozens of forms and hundreds or even thousands of
routines.

Two Questions:

1) BUILT-IN to Visual Studio 2005. What ideas do you have to quickly
navigate? For example, bookmarks help. But what other ideas do you
have? How do you quickly get to some routine you haven't looked at in
a while and you're not totally sure what the name is? Is there some
easy way to see ALL the names of ALL the routines in a project (if
there is, I'm showing my ignorance here!) Here is what I know - to
start out with:
* Bookmarks are useful. Normally they disappear when you close your
files/project - but if you leave the files open and close the
SOLUTION, then bookmarks are saved.
* Ctrl-minus and Ctrl-Shift-minus takes you back and forward among
recently edited areas.
Anyone else have further ideas?

2) Any 3rd-party add-in's that might help?

Thanks, everyone!

Rex

[Cor Ligthert [MVP]]

Rex,

I know that the development team is consequently looking for improvements
direct related to your question.

The results of those are however sometimes not as we wish. It seems that
everybody has different ideas about that. Than you get things as now is the
help. It does for me not work anymore because the complexity and the amount
of keys and steps I have to remember as well have to take to get quick the
information that I need.

For me they can make it more simple instead of more complex by adding
keystrokes or whatever. Beside that there are pointing devices, let us
forget solutions from the first days of the PC.

Just my thought,

Cor

"Rex" <rb*****@cfl.rr.comschreef in bericht
news:qr********************************@4ax.com...

Hi All - I have a question that I think MIGHT be of interest to a
number of us developers. I am somewhat new to VIsual Studio 2005 but
not new to VB. I am looking for ideas about quick and efficient
navigating within Visual Studio 2005. Let's say your project (or
solution) has dozens of forms and hundreds or even thousands of
routines.

Two Questions:

1) BUILT-IN to Visual Studio 2005. What ideas do you have to quickly
navigate? For example, bookmarks help. But what other ideas do you
have? How do you quickly get to some routine you haven't looked at in
a while and you're not totally sure what the name is? Is there some
easy way to see ALL the names of ALL the routines in a project (if
there is, I'm showing my ignorance here!) Here is what I know - to
start out with:
* Bookmarks are useful. Normally they disappear when you close your
files/project - but if you leave the files open and close the
SOLUTION, then bookmarks are saved.
* Ctrl-minus and Ctrl-Shift-minus takes you back and forward among
recently edited areas.
Anyone else have further ideas?

2) Any 3rd-party add-in's that might help?

Thanks, everyone!

Rex

[GhostInAK]

Hello Rex,

Good code organization is the most helpful. Make your classes autonomous,
so you know that a function that operates on that class will be defined within
that class. As an example.. I have a Polygon class.. and I recently needed
to see if 2 polygons intersect or if one completely contains the other..
so I could have created a module and in the module made 2 functions (PolygonsIntersect,
and PolygonContains).. this would indeed get the job done.. but it's poor
design. In a 100+ file solution you'd never find those 2 functions. Instead
I created the functions as Shared on the Polygon class.. so now when I need
to find the function that does the check for polygon intersection.. I know
it's in the Polygon.vb file. Good code organization is key.

-Boo

Hi All - I have a question that I think MIGHT be of interest to a
number of us developers. I am somewhat new to VIsual Studio 2005 but
not new to VB. I am looking for ideas about quick and efficient
navigating within Visual Studio 2005. Let's say your project (or
solution) has dozens of forms and hundreds or even thousands of
routines.

Two Questions:

1) BUILT-IN to Visual Studio 2005. What ideas do you have to quickly
navigate? For example, bookmarks help. But what other ideas do you
have? How do you quickly get to some routine you haven't looked at in
a while and you're not totally sure what the name is? Is there some
easy way to see ALL the names of ALL the routines in a project (if
there is, I'm showing my ignorance here!) Here is what I know - to
start out with:
* Bookmarks are useful. Normally they disappear when you close your
files/project - but if you leave the files open and close the
SOLUTION, then bookmarks are saved.
* Ctrl-minus and Ctrl-Shift-minus takes you back and forward among
recently edited areas.
Anyone else have further ideas?
2) Any 3rd-party add-in's that might help?

Thanks, everyone!

Rex

[Wolfgang Hauer]

Have a look at coderush
www.devexpress.com

wolfgang
"Rex" <rb*****@cfl.rr.comschrieb im Newsbeitrag
news:qr********************************@4ax.com...

Hi All - I have a question that I think MIGHT be of interest to a
number of us developers. I am somewhat new to VIsual Studio 2005 but
not new to VB. I am looking for ideas about quick and efficient
navigating within Visual Studio 2005. Let's say your project (or
solution) has dozens of forms and hundreds or even thousands of
routines.

Two Questions:

1) BUILT-IN to Visual Studio 2005. What ideas do you have to quickly
navigate? For example, bookmarks help. But what other ideas do you
have? How do you quickly get to some routine you haven't looked at in
a while and you're not totally sure what the name is? Is there some
easy way to see ALL the names of ALL the routines in a project (if
there is, I'm showing my ignorance here!) Here is what I know - to
start out with:
* Bookmarks are useful. Normally they disappear when you close your
files/project - but if you leave the files open and close the
SOLUTION, then bookmarks are saved.
* Ctrl-minus and Ctrl-Shift-minus takes you back and forward among
recently edited areas.
Anyone else have further ideas?

2) Any 3rd-party add-in's that might help?

Thanks, everyone!

Rex

[Rex]

Thanks, Cor, Boo, and Wolfgang,
Boo, thanks for your thoughtful reply - you make an excellent point
about having some excellent standard for organizing - I shall try to
implement that.
And Wolfgang - Thanks very much - CodeRusht looks like a fantastic
product - which I think will REALLY help me in my coding.
Regards,
Rex
On Wed, 30 Aug 2006 21:18:21 +0200, "Wolfgang Hauer"
<ha***@DELETETHATsysdat.atwrote:

>Have a look at coderush
www.devexpress.com

wolfgang
"Rex" <rb*****@cfl.rr.comschrieb im Newsbeitrag
news:qr********************************@4ax.com.. .

>Hi All - I have a question that I think MIGHT be of interest to a
number of us developers. I am somewhat new to VIsual Studio 2005 but
not new to VB. I am looking for ideas about quick and efficient
navigating within Visual Studio 2005. Let's say your project (or
solution) has dozens of forms and hundreds or even thousands of
routines.

Two Questions:

1) BUILT-IN to Visual Studio 2005. What ideas do you have to quickly
navigate? For example, bookmarks help. But what other ideas do you
have? How do you quickly get to some routine you haven't looked at in
a while and you're not totally sure what the name is? Is there some
easy way to see ALL the names of ALL the routines in a project (if
there is, I'm showing my ignorance here!) Here is what I know - to
start out with:
* Bookmarks are useful. Normally they disappear when you close your
files/project - but if you leave the files open and close the
SOLUTION, then bookmarks are saved.
* Ctrl-minus and Ctrl-Shift-minus takes you back and forward among
recently edited areas.
Anyone else have further ideas?

2) Any 3rd-party add-in's that might help?

Thanks, everyone!

Rex

[Miro]

I guess this brings up another question.

Do you just have a comment block on commenting what the Class / functions
.... etc do?

For example I usually do something like this:

PUBLIC CLASS
' This class blablablablbl alblablla alblalba
' balblal lbalbalb llablablaa
' and some more bla's

END CALSS

What do you guys put in there? Or do you even comment your classes /
functions like that?

-Just wondering
M.
"Rex" <rb*****@cfl.rr.comwrote in message
news:1a********************************@4ax.com...

Thanks, Cor, Boo, and Wolfgang,
Boo, thanks for your thoughtful reply - you make an excellent point
about having some excellent standard for organizing - I shall try to
implement that.
And Wolfgang - Thanks very much - CodeRusht looks like a fantastic
product - which I think will REALLY help me in my coding.
Regards,
Rex
On Wed, 30 Aug 2006 21:18:21 +0200, "Wolfgang Hauer"
<ha***@DELETETHATsysdat.atwrote:

>>Have a look at coderush
www.devexpress.com

wolfgang
"Rex" <rb*****@cfl.rr.comschrieb im Newsbeitrag
news:qr********************************@4ax.com. ..

>>Hi All - I have a question that I think MIGHT be of interest to a
number of us developers. I am somewhat new to VIsual Studio 2005 but
not new to VB. I am looking for ideas about quick and efficient
navigating within Visual Studio 2005. Let's say your project (or
solution) has dozens of forms and hundreds or even thousands of
routines.

Two Questions:

1) BUILT-IN to Visual Studio 2005. What ideas do you have to quickly
navigate? For example, bookmarks help. But what other ideas do you
have? How do you quickly get to some routine you haven't looked at in
a while and you're not totally sure what the name is? Is there some
easy way to see ALL the names of ALL the routines in a project (if
there is, I'm showing my ignorance here!) Here is what I know - to
start out with:
* Bookmarks are useful. Normally they disappear when you close your
files/project - but if you leave the files open and close the
SOLUTION, then bookmarks are saved.
* Ctrl-minus and Ctrl-Shift-minus takes you back and forward among
recently edited areas.
Anyone else have further ideas?

2) Any 3rd-party add-in's that might help?

Thanks, everyone!

Rex

[GhostInAK]

Hello Miro,

Myself I'm a big fan of self-documenting code. Keep in mind there is a right
way and a wrong way to do this. In order for your code to be self-documenting
you have to plan.. you can't simply sit down and start typing code. To make
this work you MUST have descriptive names for EVERYTHING. Something named
"Cxn" or "Cnn" just aint gonna cut it. Use fully descriptive identifiers
like "tConnection". Also, keep your function SMALL. As a general rule,
anything over 20-30 lines of code in a single function is a bad thing. Lets
say you have to set up the datatable columns, fetch some records, manipulate
them, and toss them back into the database.. This is a MINIMUM of 4 different
procedures (one for each action).. and off the top of my head I can thionk
of several helper functions that would go with them. Yes, functionally you
could roll the whole thing into a single procedure.. but it becomes hard
to read and maintain then.. and this rant is about self documenting code.
If you break it into 4 separate functions there's no need for comments in
the code describing what blocks of code does. A function called "SetupDataTable"
obviously prepares a datatable prior to filling it with data.

I've got a whole philosophy for design and implementation of software.. I
wont bore anyone with it unless ya ask me to.

Enjoy,
-Boo

I guess this brings up another question.

Do you just have a comment block on commenting what the Class /
functions ... etc do?

For example I usually do something like this:

PUBLIC CLASS
' This class blablablablbl alblablla alblalba
' balblal lbalbalb llablablaa
' and some more bla's
END CALSS

What do you guys put in there? Or do you even comment your classes /
functions like that?

-Just wondering
M.
"Rex" <rb*****@cfl.rr.comwrote in message
news:1a********************************@4ax.com...

>Thanks, Cor, Boo, and Wolfgang,
Boo, thanks for your thoughtful reply - you make an excellent point
about having some excellent standard for organizing - I shall try to
implement that.
And Wolfgang - Thanks very much - CodeRusht looks like a fantastic
product - which I think will REALLY help me in my coding.
Regards,
Rex
On Wed, 30 Aug 2006 21:18:21 +0200, "Wolfgang Hauer"
<ha***@DELETETHATsysdat.atwrote:

>>Have a look at coderush
www.devexpress.com
wolfgang
"Rex" <rb*****@cfl.rr.comschrieb im Newsbeitrag
news:qr********************************@4ax.com. ..
Hi All - I have a question that I think MIGHT be of interest to a
number of us developers. I am somewhat new to VIsual Studio 2005
but not new to VB. I am looking for ideas about quick and efficient
navigating within Visual Studio 2005. Let's say your project (or
solution) has dozens of forms and hundreds or even thousands of
routines.

Two Questions:

1) BUILT-IN to Visual Studio 2005. What ideas do you have to
quickly
navigate? For example, bookmarks help. But what other ideas do you
have? How do you quickly get to some routine you haven't looked at
in
a while and you're not totally sure what the name is? Is there some
easy way to see ALL the names of ALL the routines in a project (if
there is, I'm showing my ignorance here!) Here is what I know - to
start out with:
* Bookmarks are useful. Normally they disappear when you close your
files/project - but if you leave the files open and close the
SOLUTION, then bookmarks are saved.
* Ctrl-minus and Ctrl-Shift-minus takes you back and forward among
recently edited areas.
Anyone else have further ideas?
2) Any 3rd-party add-in's that might help?

Thanks, everyone!

Rex

[Miro]

Thanks,

That was helpful.

Im not at the stage where my Prog Is "hug" or big, but I am using
descriptive Subs and Functions and so on.

Just didnt want to end up with a huge prog and lost in my own code :)

Miro

"GhostInAK" <gh*******@gmail.comwrote in message
news:c7**************************@news.microsoft.c om...

Hello Miro,

Myself I'm a big fan of self-documenting code. Keep in mind there is a
right way and a wrong way to do this. In order for your code to be
self-documenting you have to plan.. you can't simply sit down and start
typing code. To make this work you MUST have descriptive names for
EVERYTHING. Something named "Cxn" or "Cnn" just aint gonna cut it. Use
fully descriptive identifiers like "tConnection". Also, keep your
function SMALL. As a general rule, anything over 20-30 lines of code in a
single function is a bad thing. Lets say you have to set up the datatable
columns, fetch some records, manipulate them, and toss them back into the
database.. This is a MINIMUM of 4 different procedures (one for each
action).. and off the top of my head I can thionk of several helper
functions that would go with them. Yes, functionally you could roll the
whole thing into a single procedure.. but it becomes hard to read and
maintain then.. and this rant is about self documenting code. If you break
it into 4 separate functions there's no need for comments in the code
describing what blocks of code does. A function called "SetupDataTable"
obviously prepares a datatable prior to filling it with data.

I've got a whole philosophy for design and implementation of software.. I
wont bore anyone with it unless ya ask me to.

Enjoy,
-Boo

>I guess this brings up another question.

Do you just have a comment block on commenting what the Class /
functions ... etc do?

For example I usually do something like this:

PUBLIC CLASS
' This class blablablablbl alblablla alblalba
' balblal lbalbalb llablablaa
' and some more bla's
END CALSS

What do you guys put in there? Or do you even comment your classes /
functions like that?

-Just wondering
M.
"Rex" <rb*****@cfl.rr.comwrote in message
news:1a********************************@4ax.com.. .

>>Thanks, Cor, Boo, and Wolfgang,
Boo, thanks for your thoughtful reply - you make an excellent point
about having some excellent standard for organizing - I shall try to
implement that.
And Wolfgang - Thanks very much - CodeRusht looks like a fantastic
product - which I think will REALLY help me in my coding.
Regards,
Rex
On Wed, 30 Aug 2006 21:18:21 +0200, "Wolfgang Hauer"
<ha***@DELETETHATsysdat.atwrote:

Have a look at coderush
www.devexpress.com
wolfgang
"Rex" <rb*****@cfl.rr.comschrieb im Newsbeitrag
news:qr********************************@4ax.com ...
Hi All - I have a question that I think MIGHT be of interest to a
number of us developers. I am somewhat new to VIsual Studio 2005
but not new to VB. I am looking for ideas about quick and efficient
navigating within Visual Studio 2005. Let's say your project (or
solution) has dozens of forms and hundreds or even thousands of
routines.
>
Two Questions:
>
1) BUILT-IN to Visual Studio 2005. What ideas do you have to
quickly
navigate? For example, bookmarks help. But what other ideas do you
have? How do you quickly get to some routine you haven't looked at
in
a while and you're not totally sure what the name is? Is there some
easy way to see ALL the names of ALL the routines in a project (if
there is, I'm showing my ignorance here!) Here is what I know - to
start out with:
* Bookmarks are useful. Normally they disappear when you close your
files/project - but if you leave the files open and close the
SOLUTION, then bookmarks are saved.
* Ctrl-minus and Ctrl-Shift-minus takes you back and forward among
recently edited areas.
Anyone else have further ideas?
2) Any 3rd-party add-in's that might help?
>
Thanks, everyone!
>
Rex
>

[Cor Ligthert [MVP]]

Boo,

This what you write, is my idea as well, with the exception as a class has
to give information using itelissence.

However than not so much, that the rest of the screen is unussable.

Cor

"GhostInAK" <gh*******@gmail.comschreef in bericht
news:c7**************************@news.microsoft.c om...

Hello Miro,

Myself I'm a big fan of self-documenting code. Keep in mind there is a
right way and a wrong way to do this. In order for your code to be
self-documenting you have to plan.. you can't simply sit down and start
typing code. To make this work you MUST have descriptive names for
EVERYTHING. Something named "Cxn" or "Cnn" just aint gonna cut it. Use
fully descriptive identifiers like "tConnection". Also, keep your
function SMALL. As a general rule, anything over 20-30 lines of code in a
single function is a bad thing. Lets say you have to set up the datatable
columns, fetch some records, manipulate them, and toss them back into the
database.. This is a MINIMUM of 4 different procedures (one for each
action).. and off the top of my head I can thionk of several helper
functions that would go with them. Yes, functionally you could roll the
whole thing into a single procedure.. but it becomes hard to read and
maintain then.. and this rant is about self documenting code. If you break
it into 4 separate functions there's no need for comments in the code
describing what blocks of code does. A function called "SetupDataTable"
obviously prepares a datatable prior to filling it with data.

I've got a whole philosophy for design and implementation of software.. I
wont bore anyone with it unless ya ask me to.

Enjoy,
-Boo

>I guess this brings up another question.

Do you just have a comment block on commenting what the Class /
functions ... etc do?

For example I usually do something like this:

PUBLIC CLASS
' This class blablablablbl alblablla alblalba
' balblal lbalbalb llablablaa
' and some more bla's
END CALSS

What do you guys put in there? Or do you even comment your classes /
functions like that?

-Just wondering
M.
"Rex" <rb*****@cfl.rr.comwrote in message
news:1a********************************@4ax.com.. .

>>Thanks, Cor, Boo, and Wolfgang,
Boo, thanks for your thoughtful reply - you make an excellent point
about having some excellent standard for organizing - I shall try to
implement that.
And Wolfgang - Thanks very much - CodeRusht looks like a fantastic
product - which I think will REALLY help me in my coding.
Regards,
Rex
On Wed, 30 Aug 2006 21:18:21 +0200, "Wolfgang Hauer"
<ha***@DELETETHATsysdat.atwrote:

Have a look at coderush
www.devexpress.com
wolfgang
"Rex" <rb*****@cfl.rr.comschrieb im Newsbeitrag
news:qr********************************@4ax.com ...
Hi All - I have a question that I think MIGHT be of interest to a
number of us developers. I am somewhat new to VIsual Studio 2005
but not new to VB. I am looking for ideas about quick and efficient
navigating within Visual Studio 2005. Let's say your project (or
solution) has dozens of forms and hundreds or even thousands of
routines.
>
Two Questions:
>
1) BUILT-IN to Visual Studio 2005. What ideas do you have to
quickly
navigate? For example, bookmarks help. But what other ideas do you
have? How do you quickly get to some routine you haven't looked at
in
a while and you're not totally sure what the name is? Is there some
easy way to see ALL the names of ALL the routines in a project (if
there is, I'm showing my ignorance here!) Here is what I know - to
start out with:
* Bookmarks are useful. Normally they disappear when you close your
files/project - but if you leave the files open and close the
SOLUTION, then bookmarks are saved.
* Ctrl-minus and Ctrl-Shift-minus takes you back and forward among
recently edited areas.
Anyone else have further ideas?
2) Any 3rd-party add-in's that might help?
>
Thanks, everyone!
>
Rex
>

[Wolfgang Hauer]

Hi!

I use always xml-docs. Have a look at www.roland-weigelt.de/ghostdoc . Its a
real timesave

wolfgang

"Miro" <mi******@golden.netschrieb im Newsbeitrag
news:%2****************@TK2MSFTNGP04.phx.gbl...

>I guess this brings up another question.

Do you just have a comment block on commenting what the Class / functions
... etc do?

For example I usually do something like this:

PUBLIC CLASS
' This class blablablablbl alblablla alblalba
' balblal lbalbalb llablablaa
' and some more bla's

END CALSS

What do you guys put in there? Or do you even comment your classes /
functions like that?

-Just wondering
M.
"Rex" <rb*****@cfl.rr.comwrote in message
news:1a********************************@4ax.com...

>Thanks, Cor, Boo, and Wolfgang,
Boo, thanks for your thoughtful reply - you make an excellent point
about having some excellent standard for organizing - I shall try to
implement that.
And Wolfgang - Thanks very much - CodeRusht looks like a fantastic
product - which I think will REALLY help me in my coding.
Regards,
Rex
On Wed, 30 Aug 2006 21:18:21 +0200, "Wolfgang Hauer"
<ha***@DELETETHATsysdat.atwrote:

>>>Have a look at coderush
www.devexpress.com

wolfgang
"Rex" <rb*****@cfl.rr.comschrieb im Newsbeitrag
news:qr********************************@4ax.com ...
Hi All - I have a question that I think MIGHT be of interest to a
number of us developers. I am somewhat new to VIsual Studio 2005 but
not new to VB. I am looking for ideas about quick and efficient
navigating within Visual Studio 2005. Let's say your project (or
solution) has dozens of forms and hundreds or even thousands of
routines.

Two Questions:

1) BUILT-IN to Visual Studio 2005. What ideas do you have to quickly
navigate? For example, bookmarks help. But what other ideas do you
have? How do you quickly get to some routine you haven't looked at in
a while and you're not totally sure what the name is? Is there some
easy way to see ALL the names of ALL the routines in a project (if
there is, I'm showing my ignorance here!) Here is what I know - to
start out with:
* Bookmarks are useful. Normally they disappear when you close your
files/project - but if you leave the files open and close the
SOLUTION, then bookmarks are saved.
* Ctrl-minus and Ctrl-Shift-minus takes you back and forward among
recently edited areas.
Anyone else have further ideas?

2) Any 3rd-party add-in's that might help?

Thanks, everyone!

Rex

[mg]

I find that enclosing groups of related functions using the #Region
block helps in navigation as well. Forcing yourself to group things
while creating them adds a bit of structure that is useful long after
you are familiar with the code. Being able to collapse regions while
jumping between 2 is also good.

[Peter Macej]

For example I usually do something like this:

>
PUBLIC CLASS
' This class blablablablbl alblablla alblalba
' balblal lbalbalb llablablaa
' and some more bla's

END CALSS

Commenting is very important. But as already mentioned, structured XML
comments are better way to do it. You can then automatically generate
IntelliSense info, MSDN-like documentation and F1 help. There are
various ways to achieve this, see for example my signature :)

--
Peter Macej
Helixoft - http://www.helixoft.com
VSdocman - Commenter and generator of class documentation for C#, VB
..NET and ASP .NET code

[jeff]

Boo,

the boring part to some...is the exciting part to me...

being a 'self educated' / 'self-learned' programmer ... many of my 'rules' /
'standards' have been brought about by trial and error... It is nice to read
that some of the things I do, others do as well ... many times, I have hired
(and fired) college and university grads simply because they do not know how
to code ... your code needs to reflect your problem solving skills...if you
tackle a problem as a whole and do not plan...you end up with one big sub
routine with a few calls out to other modules / classes / functions which
are so tightly connected to the current problem that 're' usability is out
the window - you spend more time trying to solve the large problem in one
fare swoop - you end up wasting time, spinning your wheels, bangin your head
off the wall ... However, if you break you problem into small, managable
tasks and tackle each task as a seperate, isolated project ... and break
these smaller projects into task...and tackle each task as a seperate,
isolated project ... for next til parent project is done ... yet get the
pictue ...

Now to the point...

your code should reflect your approach to solving the problem... in Boos
examlpe...

- focus on setting up datatable columns ... prime focus ... who cares about
the beginning and end ... you need to focus on setting up datatable columns
.... what you do after that is another problem ... how you populate them is
another problem ... Once you can setup datatable columns, move on ...

- fetch some records ... prime focus ... how do i fetch some records ...
need to connect to database ... need to query a table, call a stored proc,
query a view ... oops... this is a bigger problem with smaller tasks ... 1.
connect to database - focus / sovle ... 2. query a table for records - focus
/ solve ... 3. query a stored proc - focus / solve ... and so on.

- maniputate the data ... on the surface ... simple ... user changes data
.... done ... if there are other processes ... looking / comparing /
calculating ... isolate each routine - focus / solve ... for example ...
need to maniputate dates and phone numbers ... focus on date validition,
date formatting, date constriants ... done ... focus on phone numbers ...
validation, formatting, constraints ... done. Now, anytime you need to
'manipulate dates' ... you re-use this code ... done.

- toss back to database ... prime focus ... need to connectting to
datasource ... database, done already , xml file or other source ... focus,
code it ...

So, in the above, as Boo has already mentioned, you have at the very least 4
distinct code blocks...with four distinctly different responsibilities ...
breaking code in to logical classes, functions, procedures and so on ... is
a lot better than a code segment that needs 40 lines of text to explain 39
lines of code .... to me, over commenting is a bad thing... if you find
yourself writing just as much comments as you do code ... you need to
rethink your design approach. Now, sometimes you need to add a bunch of
comments to explain something, or refresh your memory as to why you have
implemented a certain approach ... this is fine ... but should be the
exception and not the rule in commenting your code.

Boo...I did bore...but to some, knowing others practice as you do, validates
your efforts...and makes you want to talk about it.

Thanks.
Jeff.

"GhostInAK" <gh*******@gmail.comwrote in message
news:c7**************************@news.microsoft.c om...

Hello Miro,

Myself I'm a big fan of self-documenting code. Keep in mind there is a
right way and a wrong way to do this. In order for your code to be
self-documenting you have to plan.. you can't simply sit down and start
typing code. To make this work you MUST have descriptive names for
EVERYTHING. Something named "Cxn" or "Cnn" just aint gonna cut it. Use
fully descriptive identifiers like "tConnection". Also, keep your
function SMALL. As a general rule, anything over 20-30 lines of code in a
single function is a bad thing. Lets say you have to set up the datatable
columns, fetch some records, manipulate them, and toss them back into the
database.. This is a MINIMUM of 4 different procedures (one for each
action).. and off the top of my head I can thionk of several helper
functions that would go with them. Yes, functionally you could roll the
whole thing into a single procedure.. but it becomes hard to read and
maintain then.. and this rant is about self documenting code. If you break
it into 4 separate functions there's no need for comments in the code
describing what blocks of code does. A function called "SetupDataTable"
obviously prepares a datatable prior to filling it with data.

I've got a whole philosophy for design and implementation of software.. I
wont bore anyone with it unless ya ask me to.

Enjoy,
-Boo

>I guess this brings up another question.

Do you just have a comment block on commenting what the Class /
functions ... etc do?

For example I usually do something like this:

PUBLIC CLASS
' This class blablablablbl alblablla alblalba
' balblal lbalbalb llablablaa
' and some more bla's
END CALSS

What do you guys put in there? Or do you even comment your classes /
functions like that?

-Just wondering
M.
"Rex" <rb*****@cfl.rr.comwrote in message
news:1a********************************@4ax.com.. .

>>Thanks, Cor, Boo, and Wolfgang,
Boo, thanks for your thoughtful reply - you make an excellent point
about having some excellent standard for organizing - I shall try to
implement that.
And Wolfgang - Thanks very much - CodeRusht looks like a fantastic
product - which I think will REALLY help me in my coding.
Regards,
Rex
On Wed, 30 Aug 2006 21:18:21 +0200, "Wolfgang Hauer"
<ha***@DELETETHATsysdat.atwrote:

Have a look at coderush
www.devexpress.com
wolfgang
"Rex" <rb*****@cfl.rr.comschrieb im Newsbeitrag
news:qr********************************@4ax.com ...
Hi All - I have a question that I think MIGHT be of interest to a
number of us developers. I am somewhat new to VIsual Studio 2005
but not new to VB. I am looking for ideas about quick and efficient
navigating within Visual Studio 2005. Let's say your project (or
solution) has dozens of forms and hundreds or even thousands of
routines.
>
Two Questions:
>
1) BUILT-IN to Visual Studio 2005. What ideas do you have to
quickly
navigate? For example, bookmarks help. But what other ideas do you
have? How do you quickly get to some routine you haven't looked at
in
a while and you're not totally sure what the name is? Is there some
easy way to see ALL the names of ALL the routines in a project (if
there is, I'm showing my ignorance here!) Here is what I know - to
start out with:
* Bookmarks are useful. Normally they disappear when you close your
files/project - but if you leave the files open and close the
SOLUTION, then bookmarks are saved.
* Ctrl-minus and Ctrl-Shift-minus takes you back and forward among
recently edited areas.
Anyone else have further ideas?
2) Any 3rd-party add-in's that might help?
>
Thanks, everyone!
>
Rex
>

[Cor Ligthert [MVP]]

Jeff,

I have seen programs that did more calls (whatever that were) than actual
things.

I think that Best Practise has to do with the situation it is done for.

Cor

"jeff" <jhersey at allnorth dottt comschreef in bericht
news:ud**************@TK2MSFTNGP05.phx.gbl...

Boo,

the boring part to some...is the exciting part to me...

being a 'self educated' / 'self-learned' programmer ... many of my 'rules'
/ 'standards' have been brought about by trial and error... It is nice to
read that some of the things I do, others do as well ... many times, I
have hired (and fired) college and university grads simply because they do
not know how to code ... your code needs to reflect your problem solving
skills...if you tackle a problem as a whole and do not plan...you end up
with one big sub routine with a few calls out to other modules / classes /
functions which are so tightly connected to the current problem that 're'
usability is out the window - you spend more time trying to solve the
large problem in one fare swoop - you end up wasting time, spinning your
wheels, bangin your head off the wall ... However, if you break you
problem into small, managable tasks and tackle each task as a seperate,
isolated project ... and break these smaller projects into task...and
tackle each task as a seperate, isolated project ... for next til parent
project is done ... yet get the pictue ...

Now to the point...

your code should reflect your approach to solving the problem... in Boos
examlpe...

- focus on setting up datatable columns ... prime focus ... who cares
about the beginning and end ... you need to focus on setting up datatable
columns ... what you do after that is another problem ... how you populate
them is another problem ... Once you can setup datatable columns, move on
...

- fetch some records ... prime focus ... how do i fetch some records ...
need to connect to database ... need to query a table, call a stored proc,
query a view ... oops... this is a bigger problem with smaller tasks ...
1. connect to database - focus / sovle ... 2. query a table for records -
focus / solve ... 3. query a stored proc - focus / solve ... and so on.

- maniputate the data ... on the surface ... simple ... user changes data
... done ... if there are other processes ... looking / comparing /
calculating ... isolate each routine - focus / solve ... for example ...
need to maniputate dates and phone numbers ... focus on date validition,
date formatting, date constriants ... done ... focus on phone numbers ...
validation, formatting, constraints ... done. Now, anytime you need to
'manipulate dates' ... you re-use this code ... done.

- toss back to database ... prime focus ... need to connectting to
datasource ... database, done already , xml file or other source ...
focus, code it ...

So, in the above, as Boo has already mentioned, you have at the very least
4 distinct code blocks...with four distinctly different responsibilities
... breaking code in to logical classes, functions, procedures and so on
... is a lot better than a code segment that needs 40 lines of text to
explain 39 lines of code .... to me, over commenting is a bad thing... if
you find yourself writing just as much comments as you do code ... you
need to rethink your design approach. Now, sometimes you need to add a
bunch of comments to explain something, or refresh your memory as to why
you have implemented a certain approach ... this is fine ... but should be
the exception and not the rule in commenting your code.

Boo...I did bore...but to some, knowing others practice as you do,
validates your efforts...and makes you want to talk about it.

Thanks.
Jeff.

"GhostInAK" <gh*******@gmail.comwrote in message
news:c7**************************@news.microsoft.c om...

>Hello Miro,

Myself I'm a big fan of self-documenting code. Keep in mind there is a
right way and a wrong way to do this. In order for your code to be
self-documenting you have to plan.. you can't simply sit down and start
typing code. To make this work you MUST have descriptive names for
EVERYTHING. Something named "Cxn" or "Cnn" just aint gonna cut it. Use
fully descriptive identifiers like "tConnection". Also, keep your
function SMALL. As a general rule, anything over 20-30 lines of code in
a single function is a bad thing. Lets say you have to set up the
datatable columns, fetch some records, manipulate them, and toss them
back into the database.. This is a MINIMUM of 4 different procedures
(one for each action).. and off the top of my head I can thionk of
several helper functions that would go with them. Yes, functionally you
could roll the whole thing into a single procedure.. but it becomes hard
to read and maintain then.. and this rant is about self documenting code.
If you break it into 4 separate functions there's no need for comments in
the code describing what blocks of code does. A function called
"SetupDataTable" obviously prepares a datatable prior to filling it with
data.

I've got a whole philosophy for design and implementation of software.. I
wont bore anyone with it unless ya ask me to.

Enjoy,
-Boo

>>I guess this brings up another question.

Do you just have a comment block on commenting what the Class /
functions ... etc do?

For example I usually do something like this:

PUBLIC CLASS
' This class blablablablbl alblablla alblalba
' balblal lbalbalb llablablaa
' and some more bla's
END CALSS

What do you guys put in there? Or do you even comment your classes /
functions like that?

-Just wondering
M.
"Rex" <rb*****@cfl.rr.comwrote in message
news:1a********************************@4ax.com. ..

Thanks, Cor, Boo, and Wolfgang,
Boo, thanks for your thoughtful reply - you make an excellent point
about having some excellent standard for organizing - I shall try to
implement that.
And Wolfgang - Thanks very much - CodeRusht looks like a fantastic
product - which I think will REALLY help me in my coding.
Regards,
Rex
On Wed, 30 Aug 2006 21:18:21 +0200, "Wolfgang Hauer"
<ha***@DELETETHATsysdat.atwrote:

Have a look at coderush
www.devexpress.com
wolfgang
"Rex" <rb*****@cfl.rr.comschrieb im Newsbeitrag
news:qr********************************@4ax.co m...
>Hi All - I have a question that I think MIGHT be of interest to a
>number of us developers. I am somewhat new to VIsual Studio 2005
>but not new to VB. I am looking for ideas about quick and efficient
>navigating within Visual Studio 2005. Let's say your project (or
>solution) has dozens of forms and hundreds or even thousands of
>routines.
>>
>Two Questions:
>>
>1) BUILT-IN to Visual Studio 2005. What ideas do you have to
>quickly
>navigate? For example, bookmarks help. But what other ideas do you
>have? How do you quickly get to some routine you haven't looked at
>in
>a while and you're not totally sure what the name is? Is there some
>easy way to see ALL the names of ALL the routines in a project (if
>there is, I'm showing my ignorance here!) Here is what I know - to
>start out with:
>* Bookmarks are useful. Normally they disappear when you close your
>files/project - but if you leave the files open and close the
>SOLUTION, then bookmarks are saved.
>* Ctrl-minus and Ctrl-Shift-minus takes you back and forward among
>recently edited areas.
>Anyone else have further ideas?
>2) Any 3rd-party add-in's that might help?
>>
>Thanks, everyone!
>>
>Rex
>>

[jeff]

Cor,

Agree...calling out ... is over used in a lot of cases ...

ie...

MyMath Class

MyMath.AddNumbers(aNumber1,aNumber2) as Doublle
ReTURN aNumber1 + aNumber2)
End ...

Agree, if can be overused ... I have seen it too...
Agree Best Practice is the situation it is done for ... but I have yet to
find a situation where a single code segment is best practice for a solution
to a project .

my point was to identify starting points to decide where and when to call
out to other functions / classes and so on ... when you have another problem
to solve you have a case for another 'function' 'class' 'object' whatever
.... this does not mean a decision you need to make ...

ie...

If a = b then
.....
Else
....
End if

should not be replaced with

if MyCompare(a,b) then
....
else
....
End if

Unless there is more business logic in the comparison ....because if there
is more business logic, this becomes a problem to solve rather than a
desicion...

JEff

"Cor Ligthert [MVP]" <no************@planet.nlwrote in message
news:OP**************@TK2MSFTNGP05.phx.gbl...

Jeff,

I have seen programs that did more calls (whatever that were) than actual
things.

I think that Best Practise has to do with the situation it is done for.

Cor

"jeff" <jhersey at allnorth dottt comschreef in bericht
news:ud**************@TK2MSFTNGP05.phx.gbl...

>Boo,

the boring part to some...is the exciting part to me...

being a 'self educated' / 'self-learned' programmer ... many of my
'rules' / 'standards' have been brought about by trial and error... It is
nice to read that some of the things I do, others do as well ... many
times, I have hired (and fired) college and university grads simply
because they do not know how to code ... your code needs to reflect your
problem solving skills...if you tackle a problem as a whole and do not
plan...you end up with one big sub routine with a few calls out to other
modules / classes / functions which are so tightly connected to the
current problem that 're' usability is out the window - you spend more
time trying to solve the large problem in one fare swoop - you end up
wasting time, spinning your wheels, bangin your head off the wall ...
However, if you break you problem into small, managable tasks and tackle
each task as a seperate, isolated project ... and break these smaller
projects into task...and tackle each task as a seperate, isolated project
... for next til parent project is done ... yet get the pictue ...

Now to the point...

your code should reflect your approach to solving the problem... in Boos
examlpe...

- focus on setting up datatable columns ... prime focus ... who cares
about the beginning and end ... you need to focus on setting up datatable
columns ... what you do after that is another problem ... how you
populate them is another problem ... Once you can setup datatable
columns, move on ...

- fetch some records ... prime focus ... how do i fetch some records ...
need to connect to database ... need to query a table, call a stored
proc, query a view ... oops... this is a bigger problem with smaller
tasks ... 1. connect to database - focus / sovle ... 2. query a table for
records - focus / solve ... 3. query a stored proc - focus / solve ...
and so on.

- maniputate the data ... on the surface ... simple ... user changes data
... done ... if there are other processes ... looking / comparing /
calculating ... isolate each routine - focus / solve ... for example ...
need to maniputate dates and phone numbers ... focus on date validition,
date formatting, date constriants ... done ... focus on phone numbers ...
validation, formatting, constraints ... done. Now, anytime you need to
'manipulate dates' ... you re-use this code ... done.

- toss back to database ... prime focus ... need to connectting to
datasource ... database, done already , xml file or other source ...
focus, code it ...

So, in the above, as Boo has already mentioned, you have at the very
least 4 distinct code blocks...with four distinctly different
responsibilities ... breaking code in to logical classes, functions,
procedures and so on ... is a lot better than a code segment that needs
40 lines of text to explain 39 lines of code .... to me, over commenting
is a bad thing... if you find yourself writing just as much comments as
you do code ... you need to rethink your design approach. Now, sometimes
you need to add a bunch of comments to explain something, or refresh your
memory as to why you have implemented a certain approach ... this is fine
... but should be the exception and not the rule in commenting your code.

Boo...I did bore...but to some, knowing others practice as you do,
validates your efforts...and makes you want to talk about it.

Thanks.
Jeff.

"GhostInAK" <gh*******@gmail.comwrote in message
news:c7**************************@news.microsoft. com...

>>Hello Miro,

Myself I'm a big fan of self-documenting code. Keep in mind there is a
right way and a wrong way to do this. In order for your code to be
self-documenting you have to plan.. you can't simply sit down and start
typing code. To make this work you MUST have descriptive names for
EVERYTHING. Something named "Cxn" or "Cnn" just aint gonna cut it. Use
fully descriptive identifiers like "tConnection". Also, keep your
function SMALL. As a general rule, anything over 20-30 lines of code in
a single function is a bad thing. Lets say you have to set up the
datatable columns, fetch some records, manipulate them, and toss them
back into the database.. This is a MINIMUM of 4 different procedures
(one for each action).. and off the top of my head I can thionk of
several helper functions that would go with them. Yes, functionally you
could roll the whole thing into a single procedure.. but it becomes hard
to read and maintain then.. and this rant is about self documenting
code. If you break it into 4 separate functions there's no need for
comments in the code describing what blocks of code does. A function
called "SetupDataTable" obviously prepares a datatable prior to filling
it with data.

I've got a whole philosophy for design and implementation of software..
I wont bore anyone with it unless ya ask me to.

Enjoy,
-Boo

I guess this brings up another question.

Do you just have a comment block on commenting what the Class /
functions ... etc do?

For example I usually do something like this:

PUBLIC CLASS
' This class blablablablbl alblablla alblalba
' balblal lbalbalb llablablaa
' and some more bla's
END CALSS

What do you guys put in there? Or do you even comment your classes /
functions like that?

-Just wondering
M.
"Rex" <rb*****@cfl.rr.comwrote in message
news:1a********************************@4ax.com ...

Thanks, Cor, Boo, and Wolfgang,
Boo, thanks for your thoughtful reply - you make an excellent point
about having some excellent standard for organizing - I shall try to
implement that.
And Wolfgang - Thanks very much - CodeRusht looks like a fantastic
product - which I think will REALLY help me in my coding.
Regards,
Rex
On Wed, 30 Aug 2006 21:18:21 +0200, "Wolfgang Hauer"
<ha***@DELETETHATsysdat.atwrote:
>
>Have a look at coderush
>www.devexpress.com
>wolfgang
>"Rex" <rb*****@cfl.rr.comschrieb im Newsbeitrag
>news:qr********************************@4ax.c om...
>>Hi All - I have a question that I think MIGHT be of interest to a
>>number of us developers. I am somewhat new to VIsual Studio 2005
>>but not new to VB. I am looking for ideas about quick and efficient
>>navigating within Visual Studio 2005. Let's say your project (or
>>solution) has dozens of forms and hundreds or even thousands of
>>routines.
>>>
>>Two Questions:
>>>
>>1) BUILT-IN to Visual Studio 2005. What ideas do you have to
>>quickly
>>navigate? For example, bookmarks help. But what other ideas do you
>>have? How do you quickly get to some routine you haven't looked at
>>in
>>a while and you're not totally sure what the name is? Is there some
>>easy way to see ALL the names of ALL the routines in a project (if
>>there is, I'm showing my ignorance here!) Here is what I know - to
>>start out with:
>>* Bookmarks are useful. Normally they disappear when you close your
>>files/project - but if you leave the files open and close the
>>SOLUTION, then bookmarks are saved.
>>* Ctrl-minus and Ctrl-Shift-minus takes you back and forward among
>>recently edited areas.
>>Anyone else have further ideas?
>>2) Any 3rd-party add-in's that might help?
>>>
>>Thanks, everyone!
>>>
>>Rex
>>>

[Miro]

I do find I am running into a bit of a grouping issue, as to :
when I write a bunch of custom generic functions where to store them.
For example I like to do a lot of things in arrays. So I have a function
that returns an array position of a
value, another that removes a certain element and redims the array and so
on.

Currently I added / created a MiscLibrary Module and am most likly will have
to split those up
and group them accordingly as I create more and more.
-That way Im assuming if later I try to create another program and these
functions can be re-used I am
in effect creating my own Library of Functions and Subs.
-So I can just add this Module to a different Project later.

I just started in VB.net so I really havnt run into your headaches yet of
huge programs, but i have run into them
with other languages and software created. So I am kinda following the same
rules there and slowely re-writing them
for vb.
Thats why I guess I sometimes am looking to do something really "weird" in
VB that seems "funny" to some of you when
I ask some questions here.
Just trying to code the same way in 1 langauge as in the other, and then
slowly VB'ise it. ( If VB'ise is a real word )

Books can only take you so far. I think its the experience of another
programer that does make ur life a lot simpler.

So thanks for all the help so far.
And if anyone needs help with any old 4Gl languages... like ProIV... Ask
away :-) - But thats a different newsgroup.

M.

"jeff" <jhersey at allnorth dottt comwrote in message
news:ex****************@TK2MSFTNGP04.phx.gbl...

Cor,

Agree...calling out ... is over used in a lot of cases ...

ie...

MyMath Class

MyMath.AddNumbers(aNumber1,aNumber2) as Doublle
ReTURN aNumber1 + aNumber2)
End ...

Agree, if can be overused ... I have seen it too...
Agree Best Practice is the situation it is done for ... but I have yet to
find a situation where a single code segment is best practice for a
solution to a project .

my point was to identify starting points to decide where and when to call
out to other functions / classes and so on ... when you have another
problem to solve you have a case for another 'function' 'class' 'object'
whatever ... this does not mean a decision you need to make ...

ie...

If a = b then
....
Else
...
End if

should not be replaced with

if MyCompare(a,b) then
...
else
...
End if

Unless there is more business logic in the comparison ....because if there
is more business logic, this becomes a problem to solve rather than a
desicion...

JEff

"Cor Ligthert [MVP]" <no************@planet.nlwrote in message
news:OP**************@TK2MSFTNGP05.phx.gbl...

>Jeff,

I have seen programs that did more calls (whatever that were) than actual
things.

I think that Best Practise has to do with the situation it is done for.

Cor

"jeff" <jhersey at allnorth dottt comschreef in bericht
news:ud**************@TK2MSFTNGP05.phx.gbl...

>>Boo,

the boring part to some...is the exciting part to me...

being a 'self educated' / 'self-learned' programmer ... many of my
'rules' / 'standards' have been brought about by trial and error... It
is nice to read that some of the things I do, others do as well ... many
times, I have hired (and fired) college and university grads simply
because they do not know how to code ... your code needs to reflect your
problem solving skills...if you tackle a problem as a whole and do not
plan...you end up with one big sub routine with a few calls out to other
modules / classes / functions which are so tightly connected to the
current problem that 're' usability is out the window - you spend more
time trying to solve the large problem in one fare swoop - you end up
wasting time, spinning your wheels, bangin your head off the wall ...
However, if you break you problem into small, managable tasks and tackle
each task as a seperate, isolated project ... and break these smaller
projects into task...and tackle each task as a seperate, isolated
project ... for next til parent project is done ... yet get the pictue
...

Now to the point...

your code should reflect your approach to solving the problem... in Boos
examlpe...

- focus on setting up datatable columns ... prime focus ... who cares
about the beginning and end ... you need to focus on setting up
datatable columns ... what you do after that is another problem ... how
you populate them is another problem ... Once you can setup datatable
columns, move on ...

- fetch some records ... prime focus ... how do i fetch some records ...
need to connect to database ... need to query a table, call a stored
proc, query a view ... oops... this is a bigger problem with smaller
tasks ... 1. connect to database - focus / sovle ... 2. query a table
for records - focus / solve ... 3. query a stored proc - focus / solve
... and so on.

- maniputate the data ... on the surface ... simple ... user changes
data ... done ... if there are other processes ... looking / comparing /
calculating ... isolate each routine - focus / solve ... for example ...
need to maniputate dates and phone numbers ... focus on date validition,
date formatting, date constriants ... done ... focus on phone numbers
... validation, formatting, constraints ... done. Now, anytime you need
to 'manipulate dates' ... you re-use this code ... done.

- toss back to database ... prime focus ... need to connectting to
datasource ... database, done already , xml file or other source ...
focus, code it ...

So, in the above, as Boo has already mentioned, you have at the very
least 4 distinct code blocks...with four distinctly different
responsibilities ... breaking code in to logical classes, functions,
procedures and so on ... is a lot better than a code segment that needs
40 lines of text to explain 39 lines of code .... to me, over commenting
is a bad thing... if you find yourself writing just as much comments as
you do code ... you need to rethink your design approach. Now,
sometimes you need to add a bunch of comments to explain something, or
refresh your memory as to why you have implemented a certain approach
... this is fine ... but should be the exception and not the rule in
commenting your code.

Boo...I did bore...but to some, knowing others practice as you do,
validates your efforts...and makes you want to talk about it.

Thanks.
Jeff.

"GhostInAK" <gh*******@gmail.comwrote in message
news:c7**************************@news.microsoft .com...
Hello Miro,

Myself I'm a big fan of self-documenting code. Keep in mind there is a
right way and a wrong way to do this. In order for your code to be
self-documenting you have to plan.. you can't simply sit down and start
typing code. To make this work you MUST have descriptive names for
EVERYTHING. Something named "Cxn" or "Cnn" just aint gonna cut it.
Use fully descriptive identifiers like "tConnection". Also, keep your
function SMALL. As a general rule, anything over 20-30 lines of code
in a single function is a bad thing. Lets say you have to set up the
datatable columns, fetch some records, manipulate them, and toss them
back into the database.. This is a MINIMUM of 4 different procedures
(one for each action).. and off the top of my head I can thionk of
several helper functions that would go with them. Yes, functionally
you could roll the whole thing into a single procedure.. but it becomes
hard to read and maintain then.. and this rant is about self
documenting code. If you break it into 4 separate functions there's no
need for comments in the code describing what blocks of code does. A
function called "SetupDataTable" obviously prepares a datatable prior
to filling it with data.

I've got a whole philosophy for design and implementation of software..
I wont bore anyone with it unless ya ask me to.

Enjoy,
-Boo

I guess this brings up another question.
>
Do you just have a comment block on commenting what the Class /
functions ... etc do?
>
For example I usually do something like this:
>
PUBLIC CLASS
' This class blablablablbl alblablla alblalba
' balblal lbalbalb llablablaa
' and some more bla's
END CALSS
>
What do you guys put in there? Or do you even comment your classes /
functions like that?
>
-Just wondering
M.
"Rex" <rb*****@cfl.rr.comwrote in message
news:1a********************************@4ax.co m...
>
>Thanks, Cor, Boo, and Wolfgang,
>Boo, thanks for your thoughtful reply - you make an excellent point
>about having some excellent standard for organizing - I shall try to
>implement that.
>And Wolfgang - Thanks very much - CodeRusht looks like a fantastic
>product - which I think will REALLY help me in my coding.
>Regards,
>Rex
>On Wed, 30 Aug 2006 21:18:21 +0200, "Wolfgang Hauer"
><ha***@DELETETHATsysdat.atwrote:
>>
>>Have a look at coderush
>>www.devexpress.com
>>wolfgang
>>"Rex" <rb*****@cfl.rr.comschrieb im Newsbeitrag
>>news:qr********************************@4ax. com...
>>>Hi All - I have a question that I think MIGHT be of interest to a
>>>number of us developers. I am somewhat new to VIsual Studio 2005
>>>but not new to VB. I am looking for ideas about quick and efficient
>>>navigating within Visual Studio 2005. Let's say your project (or
>>>solution) has dozens of forms and hundreds or even thousands of
>>>routines.
>>>>
>>>Two Questions:
>>>>
>>>1) BUILT-IN to Visual Studio 2005. What ideas do you have to
>>>quickly
>>>navigate? For example, bookmarks help. But what other ideas do you
>>>have? How do you quickly get to some routine you haven't looked at
>>>in
>>>a while and you're not totally sure what the name is? Is there some
>>>easy way to see ALL the names of ALL the routines in a project (if
>>>there is, I'm showing my ignorance here!) Here is what I know - to
>>>start out with:
>>>* Bookmarks are useful. Normally they disappear when you close your
>>>files/project - but if you leave the files open and close the
>>>SOLUTION, then bookmarks are saved.
>>>* Ctrl-minus and Ctrl-Shift-minus takes you back and forward among
>>>recently edited areas.
>>>Anyone else have further ideas?
>>>2) Any 3rd-party add-in's that might help?
>>>>
>>>Thanks, everyone!
>>>>
>>>Rex
>>>>

[GhostInAK]

Hello Miro,

Just a quick thought.. Nothin wrong with arrays.. but I prefer Collections
(collections, lists, hashtables, arraylists, stacks, queues, etc) as they
fit in with the object-oriented approach a lil better than standard arrays.
They also have built-in support for adding/removing/indexing and they eliminate
the need to ReDim anything. Explore both and see what you think. Also with
the addition of generics in 2.0 (Or CodeSmith for 1.1 (CodeSmith is awesome
for 2.0 as well)) the pain of creating strongly typed collections has been
soothed.

-Boo

I do find I am running into a bit of a grouping issue, as to :
when I write a bunch of custom generic functions where to store them.
For example I like to do a lot of things in arrays. So I have a
function
that returns an array position of a
value, another that removes a certain element and redims the array and
so
on.
Currently I added / created a MiscLibrary Module and am most likly
will have
to split those up
and group them accordingly as I create more and more.
-That way Im assuming if later I try to create another program and
these
functions can be re-used I am
in effect creating my own Library of Functions and Subs.
-So I can just add this Module to a different Project later.
I just started in VB.net so I really havnt run into your headaches yet
of
huge programs, but i have run into them
with other languages and software created. So I am kinda following
the same
rules there and slowely re-writing them
for vb.
Thats why I guess I sometimes am looking to do something really
"weird" in
VB that seems "funny" to some of you when
I ask some questions here.
Just trying to code the same way in 1 langauge as in the other, and
then
slowly VB'ise it. ( If VB'ise is a real word )
Books can only take you so far. I think its the experience of another
programer that does make ur life a lot simpler.

So thanks for all the help so far.
And if anyone needs help with any old 4Gl languages... like ProIV...
Ask
away :-) - But thats a different newsgroup.
M.

"jeff" <jhersey at allnorth dottt comwrote in message
news:ex****************@TK2MSFTNGP04.phx.gbl...

>Cor,

Agree...calling out ... is over used in a lot of cases ...

ie...

MyMath Class

MyMath.AddNumbers(aNumber1,aNumber2) as Doublle
ReTURN aNumber1 + aNumber2)
End ...
Agree, if can be overused ... I have seen it too...

Agree Best Practice is the situation it is done for ... but I have
yet to find a situation where a single code segment is best practice
for a solution to a project .

my point was to identify starting points to decide where and when to
call out to other functions / classes and so on ... when you have
another problem to solve you have a case for another 'function'
'class' 'object' whatever ... this does not mean a decision you need
to make ...

ie...

If a = b then
....
Else
...
End if
should not be replaced with

if MyCompare(a,b) then
...
else
...
End if
Unless there is more business logic in the comparison ....because if
there is more business logic, this becomes a problem to solve rather
than a desicion...

JEff

"Cor Ligthert [MVP]" <no************@planet.nlwrote in message
news:OP**************@TK2MSFTNGP05.phx.gbl...

>>Jeff,

I have seen programs that did more calls (whatever that were) than
actual things.

I think that Best Practise has to do with the situation it is done
for.

Cor

"jeff" <jhersey at allnorth dottt comschreef in bericht
news:ud**************@TK2MSFTNGP05.phx.gbl...

Boo,

the boring part to some...is the exciting part to me...

being a 'self educated' / 'self-learned' programmer ... many of my
'rules' / 'standards' have been brought about by trial and error...
It is nice to read that some of the things I do, others do as well
... many times, I have hired (and fired) college and university
grads simply because they do not know how to code ... your code
needs to reflect your problem solving skills...if you tackle a
problem as a whole and do not plan...you end up with one big sub
routine with a few calls out to other modules / classes / functions
which are so tightly connected to the current problem that 're'
usability is out the window - you spend more time trying to solve
the large problem in one fare swoop - you end up wasting time,
spinning your wheels, bangin your head off the wall ... However, if
you break you problem into small, managable tasks and tackle each
task as a seperate, isolated project ... and break these smaller
projects into task...and tackle each task as a seperate, isolated
project ... for next til parent project is done ... yet get the
pictue ...

Now to the point...

your code should reflect your approach to solving the problem... in
Boos examlpe...

- focus on setting up datatable columns ... prime focus ... who
cares about the beginning and end ... you need to focus on setting
up datatable columns ... what you do after that is another problem
... how you populate them is another problem ... Once you can
setup datatable columns, move on ...

- fetch some records ... prime focus ... how do i fetch some
records ... need to connect to database ... need to query a table,
call a stored proc, query a view ... oops... this is a bigger
problem with smaller tasks ... 1. connect to database - focus /
sovle ... 2. query a table for records - focus / solve ... 3. query
a stored proc - focus / solve ... and so on.

- maniputate the data ... on the surface ... simple ... user
changes data ... done ... if there are other processes ... looking
/ comparing / calculating ... isolate each routine - focus / solve
... for example ... need to maniputate dates and phone numbers ...
focus on date validition, date formatting, date constriants ...
done ... focus on phone numbers ... validation, formatting,
constraints ... done. Now, anytime you need to 'manipulate dates'
... you re-use this code ... done.

- toss back to database ... prime focus ... need to connectting to
datasource ... database, done already , xml file or other source
... focus, code it ...

So, in the above, as Boo has already mentioned, you have at the
very least 4 distinct code blocks...with four distinctly different
responsibilities ... breaking code in to logical classes,
functions, procedures and so on ... is a lot better than a code
segment that needs 40 lines of text to explain 39 lines of code
.... to me, over commenting is a bad thing... if you find yourself
writing just as much comments as you do code ... you need to
rethink your design approach. Now, sometimes you need to add a
bunch of comments to explain something, or refresh your memory as
to why you have implemented a certain approach ... this is fine ...
but should be the exception and not the rule in commenting your
code.

Boo...I did bore...but to some, knowing others practice as you do,
validates your efforts...and makes you want to talk about it.

Thanks.
Jeff.
"GhostInAK" <gh*******@gmail.comwrote in message
news:c7**************************@news.microsof t.com...

Hello Miro,
>
Myself I'm a big fan of self-documenting code. Keep in mind there
is a right way and a wrong way to do this. In order for your code
to be self-documenting you have to plan.. you can't simply sit
down and start typing code. To make this work you MUST have
descriptive names for EVERYTHING. Something named "Cxn" or "Cnn"
just aint gonna cut it. Use fully descriptive identifiers like
"tConnection". Also, keep your function SMALL. As a general
rule, anything over 20-30 lines of code in a single function is a
bad thing. Lets say you have to set up the datatable columns,
fetch some records, manipulate them, and toss them back into the
database.. This is a MINIMUM of 4 different procedures (one for
each action).. and off the top of my head I can thionk of several
helper functions that would go with them. Yes, functionally you
could roll the whole thing into a single procedure.. but it
becomes hard to read and maintain then.. and this rant is about
self documenting code. If you break it into 4 separate functions
there's no need for comments in the code describing what blocks of
code does. A function called "SetupDataTable" obviously prepares
a datatable prior to filling it with data.
>
I've got a whole philosophy for design and implementation of
software.. I wont bore anyone with it unless ya ask me to.
>
Enjoy,
-Boo
>I guess this brings up another question.
>>
>Do you just have a comment block on commenting what the Class /
>functions ... etc do?
>>
>For example I usually do something like this:
>>
>PUBLIC CLASS
>' This class blablablablbl alblablla alblalba
>' balblal lbalbalb llablablaa
>' and some more bla's
>END CALSS
>What do you guys put in there? Or do you even comment your
>classes / functions like that?
>>
>-Just wondering
>M.
>"Rex" <rb*****@cfl.rr.comwrote in message
>news:1a********************************@4ax.c om...
>>Thanks, Cor, Boo, and Wolfgang,
>>Boo, thanks for your thoughtful reply - you make an excellent
>>point
>>about having some excellent standard for organizing - I shall
>>try to
>>implement that.
>>And Wolfgang - Thanks very much - CodeRusht looks like a
>>fantastic
>>product - which I think will REALLY help me in my coding.
>>Regards,
>>Rex
>>On Wed, 30 Aug 2006 21:18:21 +0200, "Wolfgang Hauer"
>><ha***@DELETETHATsysdat.atwrote:
>>>Have a look at coderush
>>>www.devexpress.com
>>>wolfgang
>>>"Rex" <rb*****@cfl.rr.comschrieb im Newsbeitrag
>>>news:qr********************************@4ax .com...
>>>>Hi All - I have a question that I think MIGHT be of interest
>>>>to a number of us developers. I am somewhat new to VIsual
>>>>Studio 2005 but not new to VB. I am looking for ideas about
>>>>quick and efficient navigating within Visual Studio 2005.
>>>>Let's say your project (or solution) has dozens of forms and
>>>>hundreds or even thousands of routines.
>>>>>
>>>>Two Questions:
>>>>>
>>>>1) BUILT-IN to Visual Studio 2005. What ideas do you have to
>>>>quickly
>>>>navigate? For example, bookmarks help. But what other ideas do
>>>>you
>>>>have? How do you quickly get to some routine you haven't
>>>>looked at
>>>>in
>>>>a while and you're not totally sure what the name is? Is there
>>>>some
>>>>easy way to see ALL the names of ALL the routines in a project
>>>>(if
>>>>there is, I'm showing my ignorance here!) Here is what I know
>>>>- to
>>>>start out with:
>>>>* Bookmarks are useful. Normally they disappear when you close
>>>>your
>>>>files/project - but if you leave the files open and close the
>>>>SOLUTION, then bookmarks are saved.
>>>>* Ctrl-minus and Ctrl-Shift-minus takes you back and forward
>>>>among
>>>>recently edited areas.
>>>>Anyone else have further ideas?
>>>>2) Any 3rd-party add-in's that might help?
>>>>Thanks, everyone!
>>>>>
>>>>Rex
>>>>>