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