Use Project-specific Prefixes in Artifact Names

You should prefix all new source artifact names (model classes, source files, messages, message files, etc.) with a relevant acronym or abbreviated word. Use the same acronym or abbreviated word throughout. As the project progresses, this will make project additions to core artifacts more obvious. This distinction becomes very useful as the development effort grows. Generally most projects will be described by some kind of acronym. This acronym is a good candidate to use as the prefix.

Using a project-specific prefix prevents naming collisions from occurring between new artifacts that you add and new artifacts that Cúram adds over time; naming collisions can be costly and difficult to fix when they occur.

For example, consider taking on a Service Pack and discovering that one of your custom database field additions has the same name as a new application field that does not have the same business meanings or data-type. Alternatively, consider taking on a Service Pack and discovering that a new application Codetable Item has been added that conflicts with a custom Item that you also added with the same name, but a different meaning. These types of collisions can be avoided by ensuring that you always name new, custom artifacts with a consistent prefix.

Some artifact types have more than one identifier and these must be taken into account when naming them. Entity classes and Codetable Items are examples of this. A custom Entity class has a Table Name that shares the same flat namespace (the database schema) as application Tables and must have a unique Table Name within that namespace. It also has a Java class name, which shares a hierarchical namespace (package structure) with application Java classes. Likewise, a custom Codetable Item has both a value and a Java identifier – and both share a flat namespace with application items in the same Codetable.

It is important to note that the use of project specific prefixes does not apply where you are overriding an application artifact, as the override mechanism is usually based on naming your custom artifact with exactly the same name as the application artifact that it overrides.

Additional considerations:

• Identifiers come in many flavors – e.g. a filename, an XML ID, a Java class name or a combination thereof.
• A short prefix is advisable as there may be places where name lengths are restricted (e.g., certain types of database identifiers).