Names and Naming Conventions

The name you choose for an object, whether a file, class, variable, or function, must be chosen carefully. Names must be concise (no longer than necessary), descriptive (the name reflects the object's purpose), and must use correct English (no made-up, slang, or non-English language words). However, common abbreviations and acronyms are acceptable, and in fact are preferred over longer names.

Use the following naming conventions:

• For consistency and readability, all names must use lower-case, with one exception. When an object name is composed of multiple words, capitalize the first letter of each word except for the first word.
• Do not use underscores to separate words in a name. Member variable prefixes are the only exception. See Member Names for more information.
• Do not use prefixes to indicate the type of a variable. Prefixes make an object name more difficult to read. Further, experienced developers easily discern the type of a variable from the preceding declaration. Do use prefixes to indicate when a variable is a member variable. Member prefixes help developers avoid collisions between local variables and variables declared in a class. See Member Names for more information.

Examples of appropriate object names include:

    instList
    cellView
    deletedScalarNet

Examples of inappropriate object names include:

    InstMaster         Don't start with a capital letter
    pNextInst          Don't use prefixes to indicate object type (pointer in this case)
    old_index          Don't use underscore to separate words in a name
    badDog()           No slang or vernacular
    stupidFunction()   No irrelevant names

Filenames

Filenames follow the naming conventions described above, with the additional convention that source filenames must be based on the names of the objects they contain. For example, if a file contains the declaration of the oaString class, the file is called oaString.h. This rule makes it easy to discern what the file contains.

OpenAccess uses generally accepted suffixes for specific file types.

Class, Structure, and Enum Names

Classes, structures, and enums follow the naming conventions described above, with the additional convention that they must have a unique prefix that identifies the package in which they are defined. This helps protect against name clashes between similar objects developed in different packages. For example, the OpenAccess class that implements cellViews is given the name oaCellView.

Note: It is possible that we will begin using the namespace declaration supported in recent versions of ANSI C++. If this is done, a common prefix for class and structure types will be used (for example, C prefix designates a class, S prefix designates a structure, E prefix designates an enum, as in: CmyClass, SmyStruct, EmyEnum). The class,structure, and enum names will be kept unique between packages using different name spaces for each package.

Global Constant Names

In general, the use of constants such as #defines are minimized, although there are times when they are appropriate. In these cases, constants follow the naming conventions described previously, with the additional restriction that they must have a unique prefix that identifies the package in which they are defined and identifies constants as global. To handle this, a c is added to the package prefix. For example, constants defined in the OpenAccess package use the prefix oac as in oacInitialTblSize. Private constants defined in the OpenAccess package use the oav prefix as in oavAppDefTypeInt.

Macro Names

Macros are another construct that is minimized. In general, inline functions are used instead of macro functions, and static const variables are used instead of macro definitions.

If macros are required, follow these conventions:

• Use all capitalized characters with underscores between words in multi-word names.
• Use prefixes to identify the packages in which the macros are defined.

Examples of macros are:

#define	OA_MY_MACRO(x, y)
#define	OA_HARD_VAR	3 * M_PI

Important: The use of macros is always avoided at the C++ level. There are no known examples where they are needed or are appropriate in C++.

Naming Conventions in OpenAccess Translators and Utilities

The C++ namespace, file, and class names must be chosen to be consistent, unambiguous, and to avoid conflicts between packages.

Namespace Naming Conventions

Namespace names are mixed case. For example:

• oaLefDef
• oaSpef
• oaStrm
• oaVerilog
• oaUtil

Class Naming Conventions

Class names start with an upper case letter, and most class names do not have a prefix. For example:

• Exception
• Error
• HashTbl

If an application needs to be specific about the kind of error that is caught, the namespace qualifier can be used. For example:

    oaStrm::Error

For the main translator classes, the format name is included in the class name. For example, simply using In or Out is ambiguous. The LEF/DEF, SPEF, Stream, and Verilog translators use the following.

• LefIn, LefOut, DefIn, DefOut
• SpefIn, SpefOut
• StrmIn, StrmOut
• VerilogIn, VerilogOut

When there are similar classes for both the reader and writer operations, In and Out are used as a suffix to the class name. For example:

• oaVerilog::OptionsIn, oaVerilog::OptionsOut

The format name might also be needed to avoid ambiguity.

• LefInOptions, LefOutOptions

Filename Conventions

To avoid conflicts between packages in the debugger on some platforms, filenames usually use <namespace_name><primary_class_name>.cpp and <namespace_name><primary_class_name>.h. For example:

• oaVerilogException.h, oaUtilHashTbl.h

To avoid redundancy, the filenames for the main translator classes omit the format from the class name. For example:

• oaSpefIn.h instead of oaSpefSpefIn.h
• oaLefInOptions.h instead of oaLefLefInOptions.h

Return to top of page

Copyright © 2002-2010 Cadence Design Systems, Inc.
All rights reserved.