how much effort?

[wingforward]

I'm building my third Access database and I'm still learning. One thing I wonder about from "real" developers is how much effort do you put into naming conventions and other standards.

Do you name every tab, label, and combo box? Do you comment every line of VB code? Do you add only the fields you need to form queries or use the * all column? Do you get it to work or achieve some higher level of quality?

Thanks,
DJ

 

[gemma-the-husky]

labels probably not, but anything that contains data, or will become part of a tab order, and may get sed in code - yes - although if you use the wizard based on a table or query, you will find the controls are named the same as the fields on which they are based. its easier than tring to use controls named textbox1, 3, 5 etc

i put comments where i think i will need a reminder of something important

more often than not, i dont use the *, as i find i generally dont need all the columns, and i some of them for sorting, and i like to get them in a useful/logical order.


if its for someone else to use, then i think you have to try and make it as user-friendly and robust as possible

 

[georgedwilkinson]

It depends on whether you are being paid on a fixed-price contract or not. If it is a fixed-price contract, I low ball the estimate and leave out a lot of the niceties. I warn the client of such short-cuts as close to the beginning of the contract as possible (to set them up for another phase/another billing cycle).

One thing I NEVER skimp on though, is the data model. It is always correctly normalized with artificial PKs and proper business names with plain English naming conventions (plural table names and singular column names) with no prefixes or suffixes mucking up the works. It is just too important to do it wrong and I won't do a job if I cannot do a good job on the model and meet the client's other criteria.

 

[ajetrumpet]

from an amateur:

I comment almost everything, especially if I know i'm not going to be back with it for awhile, because I will forget anything and everything. I will comment as much as I need to above code blocks, and not just lines. Usually code comes in blocks regarding what it's supposed to do. That's the way I write it anyway. If you commented everyline, the redundancy would get out of hand and you would start to lose yourself in words. My opinion is that commenting is very important, especially if you are going to work with it a long time. If you build it, and he comes (from Field of Dreams), and that's it, then you dump it never to touch it again (wow, that sure sounds bad!), then comments don't mean a thing!

 

[Galaxiom]

I always name all the controls. Names like Text1 just make the coding difficult. It saves time to do it right from the start.

I never use the tblWhatever, txtAnother, qrySomething etc convention for controls except on here when making generalised code where the context is not clear. Same with VBA variables.

It just obfuscates by applying similar names to widely unconnected objects and variables. Names like intCounter are utterly pointless since counters are invariably integers.

I cringe when I see blocks like:

'Open Form
Dim strName
Dim strWhere
     strName = "frmSomeName_Form"
     strWhere = "whatever=1"
     DoCmd.OpenForm strName,,,strWhere

Aside from my pet hate of the pointless task in setting the variables, the purpose of that code is self evident. Excessive commenting just gets in the way. With intelligent variable names and good layout much coding is self evident.

However it is very important to include comments where the flow of the code is complex. Sometime a few lines describing the process at the beginning of a procedure can be more useful than similar comments dispersed through the code. Of course the occasional pointer at the start of a block is useful for navigation but it can be easier to read by explaining the overall stategy at the start.

I fix the label names at the end. It is a good chance to review the naming of the associated controls and ensure they follow a consistent unambiguous structure that others will easily follow in future.

 

[ajetrumpet]

I cringe when I see blocks like:

'Open Form
Dim strName
Dim strWhere
     strName = "frmSomeName_Form"
     strWhere = "whatever=1"
     DoCmd.OpenForm strName,,,strWhere

I totally agree. Code like that too does not need commenting either. The redundancy overfloweth.

 

[ChrisO]

DJ.

I think it largely depends on the circumstances of what you are doing.

Personally, I don’t like hard and fast rules, I find them constricting and can lead to writing ‘Sesame Street Code’.

Try to learn the reasons for the ‘where’ and the ‘when’ and not try to simulate anyone else because, they too, might be writing ‘Sesame Street Code’.

 

[Galaxiom]

Personally, I don’t like hard and fast rules, I find them constricting and can lead to writing ‘Sesame Street Code’.

Try to learn the reasons for the ‘where’ and the ‘when’ and not try to simulate anyone else because, they too, might be writing ‘Sesame Street Code’.

Excellent advice. A lot of people emulate what they see in Microsoft's documentation without even understanding why. Some of the ways Microsoft present, particularly their obsession with assignment of variables for no good reason are pointless. I have never been a fan of their Leszynski/Reddick naming conventions either.

I have heard many rules promoted in Access that have very little objective basis.

Three common ones that aught to be broken:
Every table must have a key field.
An artificial primary key is always better than a compound natural key.
Every non-trivial line of code should be commented. (Depends on definition of trivial I guess.)

 

[Atomic Shrimp]

I try to adhere to naming conventions for tables, fields, forms, reports and variables, but I find it difficult to be bothered to do the same for controls on a form or report.

I often write the comments before any code - using them as placeholders and reminders of what each process needs to do.

I indent quite religiously for conditional and looped blocks of code, or else I have trouble following the flow.

 

[wingforward]

Thanks for all the comments. You all touch on the issues I'm dealing with. I'm coming from a Filemaker Pro background where I'm comfortable with my "style" and trying to figure out my Access "style" which includes both my personal concepts of development, but also the Access "culture".

I've read, for example, that you should always use the Les/ naming convention of txt, tbl, etc because otherwise any other developer you work with won't a) understand your solution and b) won't respect your work. This is before I realized it'd be better to join a forum and ask advice rather than take the info at face value.

I prefer natural, camel case naming so it's been annoying to follow that advice and freeing to know others name naturally.

What are the characteristics of Sesame Street code?

 

[georgedwilkinson]

Use your own style. Just do it consistently.

 

[Alisa]

One thing I wonder about from "real" developers is how much effort do you put into naming conventions and other standards.

Interesting question, I put in exactly as much effort as is necessary for the solution to be maintainable and decipherable, and not an ounce more.

I specifically name any object that I work with in code, and leave everything else to whatever Access decided to name it. I do follow standard naming conventions, because then it is immediately obvious to other developers what you are doing, they don't have to sit there and figure out whatever unique and creative naming convention you made up.

I usually will put a comment at the begining of each procedure, not including event handlers. I use descriptive names for all my variables. This cuts down on the amount of comments required to explain what is going on.

 

[ChrisO]

>>What are the characteristics of Sesame Street code?<<

DJ, I’ve never been asked that before but the question seems reasonable.

Personal opinion only…

I use that term to describe beginner’s code (we were all beginners at one time) that is generated by the wizards, but works.
Since it works a lot of people keep using it and they do not develop past that stage.
There only goal seems to be to just get things working and then forget about it.

The unfortunate thing is they remain on Sesame Street and find it difficult to progress past it.
When they see some other code, or copy/paste code from somewhere else, they can’t manipulate that code for there own purposes.
They are restricted, largely because they didn’t take the time to polish their skills on the wizard code which worked.

The fact that code works does not make it good code, it requires effort to make it better.

A self imposed style, which you are looking for, is a good thing because it requires effort and self-examination.
Effort and self-examination gets people out of Sesame Street mode because they have to start thinking for themselves.

 

[gemma-the-husky]

some things are much harder to do though, and they need documenting

i dont use reusable classes, for instance - but i have just developed a project where I need to be able to store procedure names and call them with different arguments depending on circumstances. This is using eval function.

Its exceedingly powerful, and has given me a way of using reusable (sort of overloaded) code) code in a code library to achieve very flexible functionality.

This definitely needed careful annotation - I did this about 6 months ago, and it just resurfaced today!

----------
I am not sure if I did this properly, but I also found one issue with code libraries, is that if they need tables to test them, then when you call the libraries from your main database, you get a problem with the tables. So while deveoping the code library, i put the tables in there - but had to rename them, so the main database would use ITS tables with the library. Does that make sense?

 

[Alan22]

Guys & Gals,

Hi.

I've been writing applications in Access for over 10 years. Yes, I first discovered Access when version 1.1 was released.

For all these years I've been ignoring the MS style of naming variables and objects and always felt that this was because I'm another one of those people without a university degree, and therefore was not trained correctly.

It seems that after all these years, I was on the right track all.



Alan

 

[ajetrumpet]

be happy alan. think of this way:

I have way too much education and not nearly enough job experience. I'll trade seats with you, ok?

 

[boblarson]

I use a standard naming convention with most of my controls, tables, forms, and reports. This is not because I want to be like someone else, but in fact it really helps me when I'm looking at the expression builder or something and I can know right away what is a text box, combo box, list box, option frame, etc. There is no ambiguity and I need not remember what was what. It simply is what it is and I can spot things immediately. I find that to be much more efficient in my working. I do not have to take time to remember what was what.

Do I name the labels? Not unless I am going to use them in code. Do I use special naming for fields? No, I don't. But for a lot of it I want to make it easy on myself, especially 6 months to a year down the road. So, I can go quickly and make a change and find the control I need without any problem. That is why I do it that way.