Layout conventions

Symbian code is laid out in a standard way. This information is provided to help you to read Symbian code, even if you choose not to adopt the same layout yourself.


  • 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

Class layout

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


  • 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.