Developers often cling to conventions with an obsessive tenacity. This isn’t without merit. At minimum, it leads to a consistency that makes code easier to read and understand.

Experience quickly teaches us that consistency, usually born of adherence to convention, is an essential ingredient in successful projects, especially large ones. It also helps preserve the sanity of developers that maintain or extend the code later (even when it’s their own).

However, conventions have a down side when left unchallenged indefinitely. They can decay into awkward remnants of another time. Such is the case when naming components used in our applications.

For clarity, we name components to which we’ll refer in our code. A meaningful name and an abbreviation are commonly combined to produce a unique name. For example, a Tquery returning customer data might often be named, qryCustomer. So far, so good. But should the abbreviation be added as a prefix or a suffix? While convention favors a prefix, today’s environments argue for a suffix.

First of all, we’re all taught to place our adjectives before nouns. We’re used to saying Customer query, even when we see something like, qryCustomer. So why not simply place things in their natural order and write CustomerQry instead? Is this alone a good enough reason to defying the prefix convention? Probably not.

The best reason lies in the fact that our development environments have changed. We now often need to pick an item from a list. Prior to visual controls this was rarely the case.

Let’s examine a real world example. You’re working on a large application with a data module containing all lookup datasets. You frequently need to update and add to the datasets as the application is built and evolves. It wouldn’t be uncommon for such a data module to contain hundreds of datasets.

Now imagine that your assignment is to update the lookup information for dataset referencing a “Suppliers” table. When you open the object inspector and having used prefixes, you’ll be presented with a daunting search. In fact, you’ll have to scroll though dozens of entries to find the one, near the end of the list, that you seek.

Using suffixes, pressing “S” places you on or within a few down arrows of the sought after component. It wouldn’t be unusual during development to update 20, 30, 40 or more components on the same data module in a day.

On your next project, try breaking the prefix convention. Use suffixes instead and you’ll see how much time it saves. But which abbreviations should you use for your suffixes? See the article: "Delphi Standards: Naming component instances - abbreviations made easy"

Questions or Comments for the author

Copyright ©2003 Rick Ross