Layout -Conventions

Symbian code is laid out in a standard way. Symbian developers and organisations -usually have existing preferences for these issues. This information is provided -to help you to read Symbian code, even if you do not choose to adopt the same -layout yourself.

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.

+ + + + + +Layout +Conventions +

Symbian code is laid out in a standard way. Symbian developers and organisations +usually have existing preferences for these issues. This information is provided +to help you to read Symbian code, even if you do not choose to adopt the same +layout yourself.

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.

\ No newline at end of file