I'll bet the transition from the "here is what I like" type of discussion to
one based upon actual issues will be difficult but let's try
Scott wrote"you'd be doing extra work..." so the next logical question is,
what extra work? I've always used an application class to start the apps so
how much extra work have I been creating for myself? Then Tom S. suggests
that VB 2005 apps probably start with forms.
What I'm asking each person to consider is... perhaps the type of apps you
write are different (maybe the most common) but still not the only type.
There are business app, there are utilities, there are "kiosks" and there
are services. Some have no front-end, some minimal and some only need
console-based front-ends. Some (think ATM machine) typically have no menu,
and few, if any pop-up forms. Some apps are used in-house only, some are
intended for distribution and of those some to closely controlled clients
and some sold as products to the general public.
From another direction, some (and I suspect many here) are single-person
projects but that isn't too common in the business software world.
Team-based development isn't filled with "here is what I like" type
decisions or when they are the resulting app is a mess. A project estimated
to take 10 developers one year to complete isn't impacted by the "extra
work" if that means 1 minute to create a Sub Main in a class.
Programmers in typical business settings aren't (necessarily) VB experts and
it is my preference (even when the project is being written in VB) that they
are not . This has nothing to do with VB but rather a lot to do with any
self-professed language "expert." Recall the quote: "To the man with a
hammer everything looks like a nail." We've all met Access, FoxPro, VB,
Java and other language developers explaining how they could have written
the same app in half an hour and there would be no bugs. It isn't true, it
did have bugs and the apps often looked crude. They often don't aid the
user in doing their job but rather restrict the user making it harder for
them to do their job.
My point is that a style of development, the adoption of some rule, the
choice of using modules, the use of public variables, the calling of
framework methods rather than relying on VB functions, etc. is impacted by
all of the above. If a company somewhere is having a hard time
transitioning a VB6 app to .Net (assuming that is a goal) it can be in large
part because they wrote a "VB6 app" rather than an application using VB6.
Using every VB6 trick in the book can lock them into a system that is hard
to transition when no other language has whatever VB6-isms they are using.
I'm not suggesting this is a VB-only problem, the tighter the connection to
any single language the harder it will be to migrate and business needs may
dictate a migration.
So when people write "here is what I do" it might help if the person
considering it ask themself, is my situation similar? Am I writing a
similar type app, under similar conditions and intended for a similar
audience? Just because somebody writes "that's what they do at Citibank"
doesn't it make it right for you, unless perhaps you too are a large bank.
What works for your home-use contact manager program isn't likely to work
for the FDIC or NASA or on the floor of the NYSE.
Anyway that's my 2 cents (or was that 5 cents?)