<?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>