You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 4 Next »

Explains code organization, provides coding guidelines, and other information relevant to Trafodion code development.

Code Organization

To be written.

C++ Guidelines

These are the C++ coding guidelines that are part of the acceptance criteria for code submitted to the Trafodion. Trafodion reviewers use these guidelines when reviewing changes.

 

The guidelines describe practices that are either required or preferred. In addition, areas where there is no preference between two or more practices are described.

 

Trafodion is composed of several distinct sub-projects, some of which have coding guidelines that differ from the Trafodion standard; for example, a requirement in most areas of the code may be only preferred in others.

 

There may also be existing code that violates one or more of the published requirements. The intent is to correct these over time, and corrections are encouraged when changing code to make a fix or implement new functionality. However, changes that are solely coding guideline changes are not recommended since this places undue burden on the reviewers.

 

Header Files

Keep #include directives to a minimum in header files.

You may forward declare classes and structs when the only use within the header file is a pointer or reference. While includes should be kept to a minimum, if something is used in a header file and cannot be forward declared, it must be explicitly included.

All files, headers and implementation, should include everything they need to be self-sufficient. They should never assume something will be pre-included. In other words, the contents of a header file should compile cleanly by itself. To help ensure this, all implementation files should include their respective header file first.

Header files should not contain declarations for public items that are only used by the implementation file. Public items that are require in the implementation file but not the header file should be declared in the implementation file. The preference is NOT to create header files that consist only of includes of other header files.

Declare as little as possible in the header file and keep as much of the actual implementation private as is reasonable. For instance, don’t include in a header file declarations of types, enums, and functions that are only referenced by the implementation file.

  • No labels