[AccessD] Goodbye Leszynski/Reddick?

Hi Arthur

Yes, I recall your method. But I wanted to try it as simple as possible, and with the navigation in A2013 where you just can type part of an object name, I don't think sorting is a big issue.
Also, I've never managed to mix up action and select queries so I have never felt a need to name these differently.

/gustav

-----Oprindelig meddelelse-----
Fra: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] På vegne af Arthur Fuller
Sendt: 21. januar 2015 14:28
Til: Access Developers discussion and problem solving
Emne: Re: [AccessD] Goodbye Leszynski/Reddick?

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