Appendix A: Naming Conventions

One of the most important things you can do to improve the quality and readability of your code is to use standards to name variables, procedures, and objects in your database. We will now go through the importance of using naming conventions and describe one used in this book.

Why Bother?

Unfortunately, many developers dislike, and avoid using, standards. Their usual explanation is that standards stifle their creativity, or that the constant need to comply with standards distracts them from what they are really being paid to do. While there may be some truth in these claims, compliance with reasonable standards is another one of those habits that differentiates the professional from the amateur (not to mention the prima donna). Often, however, the problem lies not in the presence or content of a standard but in the spirit of its enforcement. Frequently, organizations (or the people in them) get carried away. They forget the reasons for enforcing standards and the standards become an end in themselves.

There are several valid reasons for introducing naming conventions:

• The main reason for the existence of naming conventions is to make code readable, understandable, and easy to remember.

• A standard allows developers to speak a common "language" that will help the team to communicate more efficiently.

• Team members will be able to understand and learn parts of the code with which they are not familiar.

• New team members will have to learn only one standard way of coding instead of having to learn the distinct coding habits of individual team members.

• Time will be saved and confusion avoided, since it will be easier to define and identify unique names for objects and variables.

If you are developing a project on your own, you might go through it without implementing a standard (or without being aware that you actually have a standard). However, in most cases, the introduction of a standard becomes critical, such as when the following conditions exist:

• More than one developer is working on the project.

• The code or project will be maintained or reviewed by other developers who are not currently members of the team.

• The application under development is too complex for one person to analyze all aspects at once and requires different components to be designed and implemented separately.

Conventions do not have to be complicated. To demonstrate this point, consider this simple example. If you name a variable @OrderNum, you will become confused about its contents because the name does not convey its purpose clearly. Does it contain the total number of orders or the index of a particular order? To resolve this confusion, you could establish a convention that indexes are named with "Id" and totals with "Count" at the end of the name. In this case, the variable becomes @OrderId or @OrderCount.