Naming Strategies for Dreamweaver and Various Interpreters

This work is licensed under a Creative Commons License.

Naming Strategies for Dreamweaver and Various Interpreters

Adobe.com

Naming strategies

In Dreamweaver, you can name various types of objects: images, layers, forms, files, database fields, and others. These names are later evaluated by various engines: different browsers, JavaScript interpreters, Web or application servers, query languages, and others.

If any of your various names are difficult for any of the various interpreters to recognize, this can lead to problems that can be very difficult to diagnose. One rollover may not work... a rollover may work fine until it's put into a certain layer... a particular file may not show... one particular database may not work. To make matters worse, this problem may only occur in certain situations, such as with certain browsers, or certain net connections, or only after uploading.

Guarding against invalid names

Because you can name so many different types of things, and because there are so many different engines which can evaluate names, it can be tedious to tailor naming conventions to each particular situation. It's easier to just generally name things according to the most restrictive case. This TechNote does not attempt to tell you what not to use, but instead describes general practices you can use to avoid naming conflicts.

Recommendations

Try using unique, lowercase, single-word alphanumeric names, which start with a letter and which can include underscores. The following checklist can help you devise naming practices that will help you avoid conflicts.

Make any object names unique: make sure that the same name isn't used by other objects... you may wish to append the type of object or a counter, as in "feedback_button_3".

Make any object names lowercase: some servers and script interpreters are case-sensitive, so instead of incurring subtle capitalization errors, consider making all letters lowercase. Alternatively, formalize your own capitalization pattern (such as capitalize the first letter of each word comprising the object name).

Make all names single words: spaces are evaluated differently by different interpreters... in a filename, for instance, a space character (ASCII 32) will be represented as a hexadecimal value (%20). To avoid any conflicts, always make object names single words, using the underscore character (_) where necessary to make the name more readable.

Make all letters of the name alphanumeric: the 26 lowercase letters of the Roman alphabet and its 10 digits are constant across interpreters; avoid most punctuation, diacriticals or other accented characters.

Start with a letter: some interpreters do not like object names that start with a number, so be sure to start a name with a letter ("alpha23" is fine, but "23alpha" can cause problems with JavaScript in some browsers).

Guarding against reserved names

Different interpreters may use different terms for their internal workings. It is possible to have names which conflict with the program that evaluates them. In other words, even though a particular name may be valid, it may conflict with some previously-established use.

For instance, when writing a JavaScript function, it is inadvisable to use a variable named "for". Doing so could lead to phrasings like "for (for=0...". Names like "document" and "substring" and the rest are also to be avoided. These words are already used and would obviously confuse the interpreters.

Some reserved terms aren't so obvious. Structured Query Language has long lists of reserved terms which most people never encounter. If you name a database field with a reserved SQL term, then the final SQL query itself may generate errors when the driver attempts to evaluate the request.

Be aware that it is possible to have conflicts when combining code from different sources. For example, if two JavaScript behaviors are added to the page and they both happen to reference a global variable with the same name, errors or unexpected results can occur. When troubleshooting, remember to look for a duplication in variable names within the same page.

Recommendations

Because of all this, if you wish to ensure that your own namings don't conflict with other people's namings within a document or rendering, then consider using longer names rather than generic names. The following examples illustrate how you can adjust names to be less likely to conflict with reserved names:

The name "counter" may be a reserved name, but "layer_animation_counter" should be safe.

Macromedia uses a "MM_" prefix for its prepackaged code, as in "MM_showHideLayers()". Using a similar prefix convention helps you identify all of your own namings at a glance as well as avoid possible reserved name issues.

Summary

Because it is possible to name so many different things, and because so many external engines may parse these names, it's often safest to rely on unique, lowercase, single-word alphanumeric names, which start with a letter and which can include underscores.

In some situations, a formal naming convention with namespace prefixes and object/counter suffixes can help assure unique names that will not collide with reserved terms, or names used by someone else naming items on the same page.

Additional Information

The following list of resources is a partial list of reference material describing reserved words, but developers should rely on the techniques described in this TechNote instead of hoping to avoid conflicts by knowing all reserved words.

List of reserved words in Access 2002 and Access 2003 (Microsoft article 286335)

Reserved Words (Transact-SQL Reference)

Focus on JavaScript Reserved Words

ColdFusion MX: CFC and UDF Names Cannot Match Reserved Method Names (TechNote tn_18900)

Names that are Reserved in MySQL

Top