So where does all these naming structures and schemas actually HELP a developer? They help in that whenever you look at your component file manager, everything is laid out alphabetically. If your naming schema has been consistent, it would automatically group all related variables together. I'm putting some materials together to provide an interactive example however, in the interim - here's how it helps a developer. Using this system and approach, here's some things I can do/get/report/produce in seconds - imagine trying to do them with the way you currently develop:

• a list of all components that are on one or more dialogs. (Example: all variables on all plaintiff or defendant dialogs.)
  Why? Because I might have put some variables on the wrong dialogs.
  
  
• a list of all components by type - and yes, I can see more than one variable type at a time. (Example: all date and number variables.)
  Why? Because I want to make sure they all have prompts that are consistently written.
  
  
• a list of specific variables of my own types. (Example: all percentage variables only.)
  Why? I want to change the number of decimal places handled by all percentage variables.
  
  
• a list of all address-related variables. (Example: all line 1, line 2, suburb/city, states and post/zip codes on a single screen)
  Why? I think that some address 'sets' have two address lines and some have three - I want them consistent.

The way it helps you is really simple - by having a formula behind your names, you can handle larger volumes of variables more easily, more reliably and with less handling time. Take the time to think about this for a second: Do you have a formula for file numbers? Do your matter files all have the same info, in the same order, on the front of them? Do you have procedures that you follow from day to day? Of course you do all of these things. The reason is always the same - having a formula, procedure or system just makes things easier on everyone, every day.

The above HALF the reason for using a consistent naming schema.

What's The Other Half?

It makes your templates readable by others - once they learn the formula, they can read anything you design. It means lawyers are not totally lost when they look at a template's content, because they can get a general idea of what is happening just with a quick explanation as to your formula. Sure, some lawyers would throw up their hands and flee to the hills, but then, there are many people (not just lawyers!) who would do the same! You just can't help technophobes. It also means that any mistakes you make will be more readily visible - because poorly named variables or MissPellLled variables stick out like a sore thumb.

The reasons for all this diatribe on naming schemas can be summed up like this:

A good naming schema means you can read your templates in 6 months or a years time. Someone else can read your templates in something "close to English" with very brief instructions. You wont get lost in your own code if you have to put it down for 5 minutes, because what you just did will be clear, still be clear from yesterday, and it will be clear tomorrow what is doing what, when and why in your system.