Layout Conventions

Headers

the number of headers included is minimised, forward references being preferred where possible.
the standard anti-nesting method is used to avoid multiple inclusion of headers: for example,

// EG.H -// -// Copyright notice -// - -#ifndef _EG_H_ -#define _EG_H_ -//...include files and declarations -#endif

Class layout

Symbian OS code uses the following conventions for laying out class declarations:

General

access control specifiers are always given for readability
class members are declared in the following order: public member functions, protected member functions, private member functions, protected data, private data, public data. The appropriate access specifier is given at the start of each group.
for readability, function arguments are named in the function declaration as well as the definition

Virtual functions

virtual functions that replace inherited behaviour are grouped together in the header, with a comment documenting from which class the behaviour is inherited
the virtual keyword is not given for these functions
virtual functions are not made inline, as it is difficult to know exactly how a compiler treats these. The exception to this are virtual inline destructors, which are allowed.

Inline functions

specify inline explicitly for inline functions.
do not provide the implementation in the class declaration. Instead, implementations are provided at the bottom of the header or in a separate inl file.

Headers

the number of headers +included is minimised, forward references being preferred where possible.
the standard anti-nesting +method is used to avoid multiple inclusion of headers: for example,

// EG.H +// +// Copyright notice +// + +#ifndef _EG_H_ +#define _EG_H_ +//...include files and declarations +#endif

Class layout

Symbian +code uses the following conventions for laying out class declarations:

General

access control specifiers +are always given for readability
class members are declared +in the following order: public member functions, protected member functions, +private member functions, protected data, private data, public data. The appropriate +access specifier is given at the start of each group.
for readability, function +arguments are named in the function declaration as well as the definition

Virtual +functions

virtual functions that +replace inherited behaviour are grouped together in the header, with a comment +documenting from which class the behaviour is inherited
the virtual keyword +is not given for these functions
virtual functions are +not made inline, as it is difficult to know exactly how a compiler treats +these. The exception to this are virtual inline destructors, which are allowed.

Inline +functions

specify inline explicitly +for inline functions.
do not provide the implementation +in the class declaration. Instead, implementations are provided at the bottom +of the header or in a separate inl file.