...
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.
Including Standard Header Files
The preference is for C++ style includes over C style includes for standard header files.
Code Block | ||
---|---|---|
| ||
//Preferred
#include <cstdio>
//Accepted
#include <stdio.h> |
Include Guards
All header files must use include guards. The name of the include guard #define
should be the filename in all uppercase, with underscore used in place of periods.
For instance, if the header file is named ServerInterface_ODBC.h
, the header file should begin and end as follows:
Code Block | ||
---|---|---|
| ||
#ifndef SERVERINTERFACE_ODBC_H
#define SERVERINTERFACE_ODBC_H
...
#endif /* SERVERINTERFACE_ODBC_H */ |
#endif
indicating the include guard are preferred.Variable Declaration and Naming Standards
Trafodion uses a combination of Pascal and Camel case.
- Pascal case means that the first letter in each word in an identifier is capitalized.
- Camel case is similar except the first letter is in lower case.
For both, underscores are not used to separate words. The general rule is that identifiers with local scope start with a lower case letter and identifiers with global scope start with an upper case letter.
Code Block | ||
---|---|---|
| ||
//Pascal case
class AuthenticationMessage;
//Camel case (aka lower Camel case or camelCase)
int logonCount;
Class Names |
Acceptable Examples
Code Block | ||
---|---|---|
| ||
//Preferred
class SQLSessionContext; // an object that contains the context for a SQL session
class PrivilegeList; // a list of privileges |
Poor Examples
Code Block | ||
---|---|---|
| ||
class OutputInfo; // Doesn't describe class contents, no context
class ReadTableDef; // Describes what class does, not contents
class Cmdline_Args; // Prefer Pascal case, no underscore, for class names |
Class Member Variable Names
Private member data variables should be suffixed with an underscore and should use Camel case. When names include acronyms, the acronyms should be in all upper or all lower case, dependent on which case the first letter should be.
Code Block | ||||
---|---|---|---|---|
| ||||
class Employee
{
public:
Employee ();
private:
std::string firstName_;
std::string lastName_;
uint16_t departmentNumber_;
std::string departmentName_;
uint32_t irsSSN_;
} |
Function Names
Class member functions and static file functions should use Camel case. External non-class functions should use Pascal case. Except for constructors, destructors, and operators, the function name should include a verb that describes the action the function is performing.
Good Examples
Code Block | ||
---|---|---|
| ||
/Class member functions
int32_t getSalary() const;
int32_t setAuthID();
int32_t closeAllCursors(); |
Bad Examples
Code Block | ||
---|---|---|
| ||
// Is it setting break enabled, returning it or ???
int32_t SQLCLI_BreakEnabled(); |
Enums