Useless Object Naming is when the developer makes an overzealous effort to properly name every object within every container. Don't get me wrong; there is nothing wrong with naming standards and Naming Conventions Objects is a great example of what to follow, but I have to post the following (possibly) rhetorical argument: If an object reference is never going to be used, why worry?
I don't feel an overwhelming urge to change Label1 to lblLastName. I don't worry about changing Header1 in a grid column to HdrTitle. These objects are never, ever going to referenced by any other object. I would rather invest the time spent in naming everything no matter how minute into more productive endeavors, such as solving the client's needs.
I actually do name almost every object. One reason is that I have automated tools that look for a matching label for a textbox in order to retrieve the caption information for that textbox. Another reason is that I tend to use the combobox on the properties sheet to look for an object I want to modify. If I have a long list of object named things like label12 and shape27 it bugs me. I can't easily tell where the label or shape are on the form from the name, and tend to have the urge to find out... even though I feel a little silly about that compunction.
If we work on a project with a team of programmers, or if the code will someday be handed over to another programmer for maintainence, how do we know an object will never be referenced in the code? We don't. As a consultant, I believe it is my role to write excellent, easily maintainable code -- to the best of my ability.
I do agree to a point -- I don't name objects that are obviously a part of some other component, like option buttons in an option group. And I tend to name grid components only if I have (or intend to have) code that modifies properties in the grid. I can always name the components later on if the need arises, after all. But I do name pages in my page frames. It annoys me to look at code like thisform.pageframe1.Page5.txtName. I know that seems like overkill to some, but I do change the order of my pages often enough to have reason to go through the small amount of extra effort in exchange for better clarity. -- Kristyne McDaniel
I always name the Columns of a grid (i.e. colTheFieldName), just in order to be able to tell one column from another on the property sheet object selection list. The builder to do this is pretty trivial. -- ?df
Bravo David! The first time you add major enhancements to an app that requires table structure changes that flows down to view changes and subsequent grid changes... you find out all too quickly how useful this habit is! -- Rox
Also, if an object's purpose has nothing to do with its ancestry, then there doesn't seem to be much sense in using the ancestry in its name. For example, a Security object derived from a VFP Label being named lblSecurity. Why use the lbl prefix, it adds nothing to the use of the object. A simple oSecurity would be better.
Amen to that. I have an application where the services have been grouped into 4 objects. The first is an application object, the second is a business object, and the 3rd and 4th are data services objects (local data and mainframe connectivity). 3 are Custom baseclass, the 4th is a Session. When instanced, I name them oApp, oBiz, oDB, and oMF, respectively. Frankly, why do I care about the ancestry for coding purposes? I care about the function. -- John Koziol
I think some people here are mixing Object names with Class Names also. Security classname gets instantiated to oSec the object/instance name. An instance of Text Box class becomse txtLastName object/instance name.
You could even argue it's wrong to use the "lbl" prefix there. That you're not using it as a real label, but rather that you need *some* base class, is just an artifact of the design of VFP. Think how silly you would feel if you read that Relation was lighter-weight than label, so you changed your security object to that, and then felt you had to change "lbl" to "rel" throughout your code. Yuck.
So, tell me then, what does Label17 refer to? The trouble is that as it stands Label17 tells you nothing except that it's a label. If you need to know what it refers to you have to go and find it and read what it says. lblLastName at least gives you the hint about what it's for even if you never reference it. I've found that saying 'never' is a pretty good way of ensuring that you 'll need to do the very thing you said 'never' to. Think how silly you would feel if you needed to refer to the LastName label and then spend time to find out what it was called, and then, later, everytime you return to your code and find the reference Lable17 you have to go and look for the damn thing again to remind yourself what it is.
The amount of time spent to name every object according to Hoyle in the event that I might actually need that name in the future is counter-productive. If, in the future, I need Label17 to become lblLastName because a code change requires an addressing of that label, so be it. But why spend the time upfront?
But, it probably wouldn't take much for some sharp person here to create a quick builder/wizard that named all the text boxes based on their control source. If you are really sharp, it could name labels based on the control source of the textbox that is next in the tab order. You would have to set your tab order first of course. But, at least naming all the bound controls gets you most of the way there. That just leaves you to name containers that you will reference in code.
Besides which, take a look at someone's code that's littered with TextBox1 and Label1 and so forth. How difficult is it to read compared with txtLastName and lblLastName. May not make a difference now, but 6 months down the road...or you have to debug someone's code that is consistent in *not* renaming objects, rather you than me.
Not that difficult at all. In fact, if I look and see an object with a name like Label17 I know it's a damn good bet that I don't have to worry about that object. Now, interactive objects, like a Text Box, is a whole 'nother ball of wax.
On the other hand, consider a container object that is being used as a mediator to the contained objects. There is no need for the outside world to ever be involved with the names of the contained objects. All communication is through the container. The container can easily iterate through its collection of contained objects to send messages and messages from the contained objects are to the container. The only object name that is really of any importance in this design is the name of the container. Ah, but when implementing the mediator/container object itself, it's easier to work with properly (read: mnemonically) named (containee) objects. Art Bergquist
If you need to have a reference to an object, name the object. If you don't, there's little reason aside from completeness to go and name each object. Data controls are a different matter than label or other non-data controls; a data control's name is displayed on the form and forms an important design reference to it in the mind of the programmer. Even if the developer never specifically references that control in code, it still needs a name.
While there's some thought that might be put into if you should name ALL of your objects, can we agree that you should NEVER, NEVER, NEVER NEVER code without names (unless you SWEAR it's only for testing a theory!)? I never want to see this (again):
-- Peter Crabtree
One point that isn't often considered: Visual controls that get focus report their names to the Microsoft Active Accessibility (MSAA) API. Some screenreader programs for blind users speak this name when the control gets focus.
Many developers use the common convention of prefixing subclassed controls with the initals of their company, followed by a designation of the base class, followed by a meaningful name. Consider this example from the My Software Company, as spoken by a screenreader: "Em Ess See Tee Ex Tee Lastname" (MSCtxtLastname). What the heck is that? The problem is complicated by the fact that most experienced blind computer users run their speech software at very fast speeds. This allows them to process aural input almost as fast as sighted people can read, but only if that input is expressed in natural language. Control names like this sound like gibberish at those speeds.
On the other hand, the baseclass names aren't helpful at all to blind users. When a list dialogue pops up and the listbox gets focus, it isn't very informative to be told that you're looking at "list1"--which may be all that the screenreader says unless and until the user starts looking around the form manually.
For accessibility purposes, a meaningful name that is devoid of "conventional" abbreviations is best: LastName. ClientList. Step2 (for a wizard).
-- Ken Dibble
An interesting consideration, Ken. And if it's good enough for blind users it should be good enough for the sighted too. I could trade-off with "LastNameLabel" and "LastNameEntry" or a variation of that. --JimNelson
Label name properties are less of a consideration, because labels can't get focus. If a blind user uses a screen reader's "line read" function, it will read any VFP label.caption text on the current "line" without announcing the label name, but it's a problem finding a way to tell the user there's something to read there, and the "line read" function applies to the entire desktop, not to any one particular window or application. (The only reliable ways to get a screen reader to speak a specific piece of "message" or "title" text on a form automatically in VFP are to put it in a borderless, plain, read-only textbox or editbox (which looks kind of funky when a sighted user tabs around the form), or have it appear on a MESSAGEBOX (where it can't be formatted).) So it's also a bad idea to use a label as a clickable control, unless it is simply there to provide alternate access to the functionality of an associated control that can get focus and does the same thing as the clickable label when activated. At any rate, this problem isn't exclusive to VFP--it's an issue for any visual control that can't get focus in Windows. Usually the answer is to spend lots and lots of time creating application-specific configuration files for the screen reader.
Adding the word "entry", or something similar, to a textbox control's name, however, may still be confusing--or annoying.
I should clarify that this issue only relates to the name properties of instances of controls that can get focus. Class names aren't a problem.
And since it's very useful to be able to process a bunch of controls at once based on something they have in common, I suggest a couple of, perhaps obvious, alternate ways to do that without creating confusing or annoying control names:
To summarize: While it takes a bit more work to give each instance of a control class a meaningful name, it doesn't take any more work to give it one that isn't confusing. There's no absolute need for the name property to contain a handle suitable for batch processing because other properties that aren't used by screenreaders can be used for the same purpose.
- 1. Put a "handle" string in the .Tag property of the class:
MyTextboxClass.Tag = "date_entry"
FOR EACH oControl IN THISFORM.Controls
CASE "date" $ oControl.Tag
CASE "entry" $ oControl.Tag
*Do something else
- 2. Use the .class property as the handle:
FOR EACH oControl IN THISFORM.Controls
IF oControl.Class = "Mytextboxclass"
*Do something to it.
- 3. Add a custom property to your subclass that does the same thing:
MyTextboxClass.HandleName = "date_entry"
-- Ken Dibble
Contributors: John Koziol Steven Black Jim Booth Randy Pearson Mark Austen William OConnor Kristyne McDaniel Peter Crabtree
Category Standards And Conventions
( Topic last updated: 2003.02.11 10:50:26 PM )