[AccessD] Goodbye Leszynski/Reddick?

Stuart McLachlan stuart at lexacorp.com.pg
Wed Jan 21 15:20:18 CST 2015


Good one :)

Wonder how may will get it straight away?

-- 
Stuart

On 21 Jan 2015 at 12:07, Bill Benson wrote:

> Hungarian prefix perhaps, not suffix?
> 
> On Wed, Jan 21, 2015 at 8:28 AM, Arthur Fuller
> <fuller.artful at gmail.com> wrote:
> 
> > Gustav,
> >
> > Although I've used Leszynski/Reddick conventions in the past,
> > several years ago I abandoned them, in favour of what I call
> > Hungarian suffix notation. It's basically the same, but rather than
> > prefixes I use suffixes. My justification for this is simple: signal
> > to noise ratio. It is inefficient to me to have to ignore the first
> > three letters of any given object name. Further, objects don't sort
> > intelligently when prefixes are used.
> >
> > I've even gone a little beyond that, in my use of suffixes.
> > Specifically, queries/views:
> >
> > Queries use these suffixes:
> > SalesReports_qs         'query Select
> > CustomersTotals_qu    'query Update
> > Invoices_qa                 'query append
> > TempTable_qd             'query delete
> >
> > Views use similar suffixes, substituting "v" for "q".
> >
> > Forms use suffixes such as "_frm" (normal form), "_sfm" (subform),
> > "_dlg" (dialog), and "_ds" (datasheet).
> >
> > When working with a SQL back end, I do the something similar. My
> > typical suffix is "_ap" (application procedure), and within the name
> > itself I always begin with the principal table(s), especially in the
> > case of sprocs that update the data. It's strictly a matter of
> > choice, but my preference is "object-action" rather than
> > "action-object": I won't use "UpdateOrder" for example, but rather
> > "OrderUpdate". Again, objects sort more naturally this way.
> >
> > Ultimately, I suppose that whichever scheme you employ, consistency
> > is the watchword. When working on a project that will be maintained
> > by someone else when I'm gone, I include a module called
> > "_Conventions" that consists of nothing but comments, and describes
> > the conventions outlined above. ------ Thanks for the code, Gustav.
> > I've copied it into my OneNote notebook of VBA code, with full
> > credit to you of course.
> >
> > /Arthur
> >
> > On Wed, Jan 21, 2015 at 7:44 AM, Gustav Brock <gustav at cactus.dk>
> > wrote:
> >
> > > Hi all
> > >
> > > I had to write a new VBA project from scratch, and given how you
> > > conventionally program in C# and that Microsoft never has applied
> > > the Leszynski/Reddick naming convention (just study the parameter
> > > names of
> > the
> > > built-in functions), I thought it might be time for a change, if
> > > for nothing else to type less.
> > >
> > > So I did, and I felt well. Now Key can be the name (string) of a
> > > key,
> > Keys
> > > an array of keys, and Value the value of a key, and DataCollection
> > > is a collection of data.
> > >
> > > Much to my surprise, having used Leszynski/Reddick "always" it
> > > didn't cause any problems to me - in fact I find the code just a
> > > little bit
> > easier
> > > to read.
> > > That may be me, and we all have our preferences, but have a look
> > > and
> > judge
> > > for yourself:
> > >
> > >     https://github.com/CactusData/VBA.CVRAPI
> > >
> > > Now, this is code only - no tables, no queries - and that may be
> > > where trouble is; it is very convenient from the name alone to
> > > know whether you deal with a table or a query, even though a table
> > > and a query cannot
> > share
> > > the same name.
> > > I've seen, that in T-SQL you often prefix views with a V, so
> > > Customer is
> > a
> > > table and VCustomer is some query/view of table Customer. So a
> > > simple prefix of Q for query names could be used. I haven't sorted
> > > that out yet.
> > >
> > > /gustav
> > --
> > AccessD mailing list
> > AccessD at databaseadvisors.com
> > http://databaseadvisors.com/mailman/listinfo/accessd
> > Website: http://www.databaseadvisors.com
> >
> -- 
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
> 




More information about the AccessD mailing list