Rules and Standards

General Principles

The following general principles have been established when choosing rules for CAA V5 names:

1. Brand-based prefixes. A prefix [1] is used for most entities that may collide with other entities of the same nature, but developed outside the Dassault Systèmes (DS) Group. It denotes the DS origin of the entity. Other entity suppliers, and in particular CAA partners, are expected not to begin their names with DS reserved prefixes. Prefixes are based on DS brandnames, because of their perennity: CAT for CATIA, VPM and ENOV for ENOVIA, DNB for DELMIA)
2. Aliases for frameworks. All frameworks (FW) are assigned a short 3-letter alias with first letter capitalized (e.g. CATDialog-> Dlg) [2]. This alias is used as a shortcut for the framework name for building other framework related names. It is referred to as <FWAlias> in the remaining of this document. Framework aliases will be defined in the framework's identity card. Trigrams are typically used to name entities that are associated to frameworks (e.g., modules). Since all modules from all frameworks are merged at runtime into common repositories (e.g., RuntimeView), trigrams provide a means of avoiding conflicts. For a given framework FW, the same trigram applies to the framework and to its associated FW.tst and FW.edu frameworks.
3. English. Names are based on english/american words.

[Top]

Global Rule

[Top]

Entities Associated with a Directory

The entity and the directory that contain it must have the same name.

[Top]

C++ Entities Associated with a File

A file, or a pair of files, must be dedicated to the following entities, that must have the same name than the files:

• C++ classes and extension classes
• C++ and Automation interfaces
• Global functions, enumerations, and macros.

[Top]

Language-independent Entities Associated with a File

[Top]

User Interface Entities

These rules apply to the identifiers assigned to the user interface entities to ensure their uniqueness when you add a workbench or an add-in.

[Top]

Other Entities

[Top]

Naming Variables Within C++ Code

Rules described in this section are 'best practices' for V5 code and mandatory for CAA code.

General Rules

• variable names are to begin with a lowercase letter (int counter;)
• function names are to begin with an Uppercase letter (void CountItems();)
• * and & are to be collated to the variable name, not the type name, in order to avoid ambiguities in case of multiple definitions on the same line
  CATBaseUnknown *pFirstItem, *pSecondItem;
• data members are to begin with an underscore (int _length). Data members should never be assigned public (in the C++ sense) visibility.

Hungarian Notation

It consist in putting a prefix in front of the name that reminds the reader of some aspect of the type of the variable (ex. is it an array?). The advantage is that it allows a better understanding of the valid operations that can apply to a certain type (ex. delete applies to a pointer, delete [] to an array).

Here is a table of standard hungarian prefixes defined for CAA V5:

Note: when writing method signatures, the hungarian notation combines with the i, o, io prefixes that denotes the direction of information flow within arguments (f(CATISpecObject **ioppTargetFeature) denotes a pointer to a pointer to a feature that is used as input-output arguments -- i.e. after f() is run, the feature accessed through ioppTargetFeature might be a different one).

[Top]

Naming Interface Pointers

Many interface pointers may be used in the same scope to manipulate one single implementation by different "behavioral handles". If those interface pointers bear very different names, figuring out that in fact one single object is being manipulated required a mental effort.

To avoid it, the following scheme is adopted:

1. Choose a (short) identifier to refer to the implementation (e.g. Doc for a document) as a root name
2. Forge a derived name around this root name when you manipulate this implementation through an interface pointer, by using the following pattern pi<InterfaceName>On<RootName>. Interface name is obtained by removing the <prefix>I prefix from its class name. For instance, piInitOnDoc and piPersistentOnDoc are two interface pointers (pi) by which a document implementation referred to as Doc is manipulated through interfaces of type CATIInit (Init) and CATIPersistent (Persistent) respectively.

[Top]

References

History

Copyright © 2000, Dassault Systèmes. All rights reserved.