--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/Symbian3/SDK/Source/GUID-79E8BE3D-9EF7-5275-A245-3CF689E58DE9.dita	Wed Mar 31 11:11:55 2010 +0100
@@ -0,0 +1,60 @@
+<?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>
\ No newline at end of file