good practice for VB code

[Erik De Keyser]

Hi group,

I have a couple of projects with up to 8 forms.
On most projects I write the code on each form with no modules.
The last project I use 1 module and minimal code on each form , in fact just the
code for each visual object, and all the subroutines are placed in a module.

What is the best practice where I can place my VB code, at each form or in a
separate module ?
Pro's & con's ? Performance benefit ?

Tnx

--
Erik De Keyser - Belgium

[CajunCoiler \(http://www.cajuncoiler.tk\)]

Re: good practice for VB code

Simple solution...
* Routines used more than once, or by more
than one form, dump em into a module.
* Routines used once, leave it in the form that uses it.

"Erik De Keyser" <edk@hotmail.co m.invalid> wrote in message
news:3fff070b$0 $1156$ba620e4c@ news.skynet.be. ..[color=blue]
> Hi group,
>
> I have a couple of projects with up to 8 forms.
> On most projects I write the code on each form with no modules.
> The last project I use 1 module and minimal code on each form , in fact[/color]
just the[color=blue]
> code for each visual object, and all the subroutines are placed in a[/color]
module.[color=blue]
>
> What is the best practice where I can place my VB code, at each form or in[/color]
a[color=blue]
> separate module ?
> Pro's & con's ? Performance benefit ?
>
> Tnx
>
> --
> Erik De Keyser - Belgium
>
>[/color]

[J French]

Re: good practice for VB code

On Fri, 9 Jan 2004 15:05:33 -0600, "CajunCoile r
\(http://www.cajuncoiler .tk\)" <poohbear1961@t otallyspamless. cox.net>
wrote:
[color=blue]
>Simple solution...
> * Routines used more than once, or by more
> than one form, dump em into a module.
> * Routines used once, leave it in the form that uses it.[/color]

Yup

And 'mundane' stuff dealing with Controls
- into UserControls (not OCXes) included in the Project

[Dikkie Dik]

Re: good practice for VB code

Erik De Keyser wrote:
[color=blue]
> What is the best practice where I can place my VB code, at each form or in a
> separate module ?
> Pro's & con's ? Performance benefit ?[/color]

Everything that belongs to a specific task can generally be grouped in
one or more class modules. This has the advantage of reusability and
testability: You can have more instances of the same functionality and
you can write unit tests before writing the actual implementation.
You could compare this with the way a modern audio device like a radio
is built: there are separate "classes" for amplification, recieving,
etc. These components may or may not be made by the manufacturer
himself, and can easily be replaced and tested without the rest of the
device.

Try to make your (class) modules as independent as possible from the
rest of your code, as this will make it easier to reuse them in other
projects.

What is left in the forms is the "driving" of the classes that are your
actual application. When you follow this model, you have created a
separate User Interface layer and an application layer. Especially
Microsoft likes you to do that, so that you can easily transform or
expand your application into a web application.

One final word: to be honest, there is no universal good design for all
applications. For some applications, a multi-layer design can be by far
the best option, for others it can be an absurd overkill to a simple
problem. Do not be afraid to let the design of an application evolve.
When you have unit tests, you can refactor the design whenever you need
to. I can recommend the book "Refactorin g - Improving the Design of
Existing Code" by Martin Fowler if you want to read more about
controlled adaptation of a software design.
I think the design must fit both the software and the programmer. When
you are feeling you are doing the same trick every day, you will
probably be ready to move general pieces of code into their own (class)
modules and use them in other applications as well. This may be an
obvious improvement in the design, but if you had seen your colleague
doing that when you first started to learn to program, you had probably
seen this as unnecessarily complicated.

Just don't be afraid to improve your own code and you'll grow into an
acceptible good practice.

Best regards