Computer Hardware Algorithm Standard User's Guide

www.ti.com
3.1.2 Naming Conventions
3.1.3 Module Initialization and Finalization
3.1.4 Module Instance Objects
Interfaces and Modules
To simplify the way eXpressDSP-compliant client Code is written, it is valuable to maintain a single
consistent naming convention. In addition to being properly prefixed (Rule 8), all external declarations
disclosed to the user must conform to the eXpressDSP naming conventions.
Rule 10
All modules must follow the eXpressDSP-compliant naming conventions for those external declarations
disclosed to the client.
Note that the naming conventions only apply to external identifiers. Internal names and existing Code
need not change unless an identifier is externally visible to a client application. The eXpressDSP naming
conventions are summarized in the table below.
Convention Description Example
Variables and functions begin with
Variables and functions FIR_apply()
lowercase (after the prefix).
Constants Constants are all uppercase G729_FRAMELEN
Data types are in title case (after the
Types FIR_Handle
prefix)
Structure fields Structure fields begin with lowercase buffer
Macros follow the conventions of constants
macros FIR_create()
or functions as appropriate
In addition to these conventions, it is important that multi-word identifiers never use the '_' character to
separate the words. To improve readability use title case; for example, FIR_getBuffer() should be used in
lieu of FIR_get_buffer(). This avoids ambiguity when parsing module and vendor prefixes.
Before a module can be used by an application, it must first be "initialized"; i.e., the module's init() method
must be run. Similarly, when an application terminates, any module that was initialized must be "finalized,"
i.e., its exit() method must be executed. Initialization methods are often used to initialize global data used
by the module that, due to limitations of the C language, cannot be statically initialized. Finalization
methods are often used to perform run-time debug assertions; for example, it might check for objects that
were created but never deleted. The finalization method of a non-debug version of a module is often the
empty function.
Although some modules have no need for initialization or finalization, it is easier for the clients of modules
to assume that all modules have them. This allows frameworks to easily implement well-defined startup
and shutdown sequences, for example.
Rule 11
All modules must supply an initialization and finalization method.
Modules optionally manage instance objects. All eXpressDSP-compliant modules manage instance
objects. Objects simply encapsulate the persistent state that is manipulated by the other functions or
methods provided by the module.
A module manages only one type of object. Thus, a module that manages objects roughly corresponds to
a C++ class that follows a standard naming convention for its configuration parameters, interface header,
and all external identifiers as shown in Figure 3-2 .
28 Algorithm Component Model SPRU352G – June 2005 – Revised February 2007
Submit Documentation Feedback