<?xml version="1.0" encoding="utf-8"?>
<!-- Copyright (c) 2007-2010 Nokia Corporation and/or its subsidiary(-ies) All rights reserved. -->
<!-- This component and the accompanying materials are made available under the terms of the License 
"Eclipse Public License v1.0" which accompanies this distribution, 
and is available at the URL "http://www.eclipse.org/legal/epl-v10.html". -->
<!-- Initial Contributors:
    Nokia Corporation - initial contribution.
Contributors: 
-->
<!DOCTYPE concept
  PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd">
<concept id="GUID-79E8BE3D-9EF7-5275-A245-3CF689E58DE9" xml:lang="en"><title>Layout
Conventions</title><prolog><metadata><keywords/></metadata></prolog><conbody>
<p>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. </p>
<section id="GUID-18F0A290-4228-4637-9E05-90A135F34C30"><title>Headers</title> <ul>
<li id="GUID-F50F1F83-A9D6-590B-AA12-239823B40B27"><p>the number of headers
included is minimised, forward references being preferred where possible. </p> </li>
<li id="GUID-FECBB5C1-0C45-52AF-8CA3-B9F62801EFCA"><p>the standard anti-nesting
method is used to avoid multiple inclusion of headers: for example, </p> </li>
</ul> <codeblock id="GUID-744E1BA3-112B-5F0E-9A41-82AD6A1B7C00" xml:space="preserve">// EG.H
//
// Copyright notice
//

#ifndef _EG_H_
#define _EG_H_
//...include files and declarations
#endif</codeblock> </section>
<section id="GUID-342D5A59-8489-495C-B619-48FF24B11029"><title>Class layout</title> <p>Symbian
code uses the following conventions for laying out class declarations: </p> <p><b>General</b> </p> <ul>
<li id="GUID-46510CC9-C7B0-528E-BB68-7A64BFC7BC61"><p>access control specifiers
are always given for readability </p> </li>
<li id="GUID-5EEB5EDA-848E-55C4-A9E8-8DDFE3091A01"><p>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. </p> </li>
<li id="GUID-4A576792-75EA-543A-A6B4-B5357E4AE850"><p>for readability, function
arguments are named in the function declaration as well as the definition </p> </li>
</ul> <p><b>Virtual
functions</b> </p> <ul>
<li id="GUID-A66F4D3B-B259-59D8-9519-E173E4071015"><p>virtual functions that
replace inherited behaviour are grouped together in the header, with a comment
documenting from which class the behaviour is inherited </p> </li>
<li id="GUID-16B867BB-7612-5D89-8E8E-947645EB3677"><p>the <codeph>virtual</codeph> keyword
is not given for these functions </p> </li>
<li id="GUID-42B49550-7AEE-5E30-825C-5F17F5DBB300"><p>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. </p> </li>
</ul> <p><b>Inline
functions</b> </p> <ul>
<li id="GUID-00EEDE0A-3BC8-5359-B82A-7E864713F63E"><p>specify <codeph>inline</codeph> explicitly
for inline functions. </p> </li>
<li id="GUID-C0F56E55-A81D-578F-8605-6FF7A1ACB7A5"><p>do not provide the implementation
in the class declaration. Instead, implementations are provided at the bottom
of the header or in a separate <filepath>inl</filepath> file. </p> </li>
</ul> </section>
</conbody></concept>