[dba-VB] VB.Net 2005 - Regions

Charlotte Foust cfoust at infostatsystems.com
Fri Jun 15 11:44:44 CDT 2007


That's much the way I started out too, John, but I found after a while
that it depends entirely on what kind of a class you're dealing with, so
a standard structure doesn't stay standard for long.  

I never collapse my module level declarations and constants because when
they're uncollapsed I can scroll back up and look at them without losing
my insertion point, so I don't put them in a region.  I group routines
that "belong" together functionally in the same region.  For instance, I
have a Setup region that might include things like a custom constructor,
a MyBase.Load event, an initialization routine (usually called FillData
for forms and usercontrol/subforms), a declaration and initialization of
typed columns for working with a grid, InitializeLayout for the grid,
etc.  If the class is a form or subform, I'll have a validation region
that includes the routines implementing our validation interface, as
well as any BeforeUpdate events, form Validation or Validating events,
etc, that call into or trigger the validation.  I throw miscellaneous
stuff into a Methods region, but our exceptions are handled in calls to
exception handlers, rather than within an individual class. We use
helper classes as much as possible to standardize things like exception
handling, and we use quite a few customized user controls that include
the features we want to reduce the code required in the class that uses
the control. 

Our data provider classes and our data entity classes have their own
structural peculiarities, so they're broken up differently.  A data
entity, which inherits a typed dataset and implements a custom
interface, has regions based around constructors, Get and Fill
operations, update, business rules and any children it exposes.  A data
provider usually has regions for each of the tables it handles, with
subregions for the Fill operations (and overloads), update operations
and "Other", which includes things like the NextID for a particular
table.

Over time, your use of regions will evolve if you let it, especially as
you work with controls and tools that have their own sets of events to
handle.  I even know of one developer who uses an alphabetic scheme for
his regions, so all the routines with names that start with M or N or O
would be grouped together! LOL

Charlotte Foust

-----Original Message-----
From: dba-vb-bounces at databaseadvisors.com
[mailto:dba-vb-bounces at databaseadvisors.com] On Behalf Of jwcolby
Sent: Friday, June 15, 2007 9:03 AM
To: dba-vb at databaseadvisors.com
Subject: [dba-VB] VB.Net 2005 - Regions

I like regions for organizing classes.  It just works for me to have my
classes organized such that things are in the same places down through
the class.  I set up this regions structure:

#Region "Header"
#Region "Variables"
#End Region

#Region "Constants"
#End Region

#Region "Enums"
#End Region

#Region "Structures"
#End Region

#Region "Events"
#End Region

#Region "Win32API"
#End Region
#End Region

#Region "Properties"
#End Region

#Region "Methods"
#End Region

#Region "Exceptions"
#End Region

Thus I have a header region, with subregions for grouping variables,
constants etc.  Below the header region I have a handful of regions to
group properties, methods and exceptions.  Once I set up my regions, I
inserted it into the snippets so that I could just insert a regions
snippet first thing after I define a blank class.  I can also insert a
regions snippet at the top of the class to "retrofit" an existing class
and clean it up.

Comments welcomed.

John W. Colby
Colby Consulting
www.ColbyConsulting.com 




More information about the dba-VB mailing list