12 <concept xml:lang="en" id="GUID-79E8BE3D-9EF7-5275-A245-3CF689E58DE9"><title>Layout Conventions</title><prolog><metadata><keywords/></metadata></prolog><conbody><p>Symbian OS 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 OS code, even if you do not choose to adopt the same layout yourself. </p> <section><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

    12 <concept id="GUID-79E8BE3D-9EF7-5275-A245-3CF689E58DE9" xml:lang="en"><title>Layout

    13 Conventions</title><prolog><metadata><keywords/></metadata></prolog><conbody>

    14 <p>Symbian code is laid out in a standard way. Symbian developers and organisations

    15 usually have existing preferences for these issues. This information is provided

    16 to help you to read Symbian code, even if you do not choose to adopt the same

    17 layout yourself. </p>

    18 <section id="GUID-18F0A290-4228-4637-9E05-90A135F34C30"><title>Headers</title> <ul>

    19 <li id="GUID-F50F1F83-A9D6-590B-AA12-239823B40B27"><p>the number of headers

    20 included is minimised, forward references being preferred where possible. </p> </li>

    21 <li id="GUID-FECBB5C1-0C45-52AF-8CA3-B9F62801EFCA"><p>the standard anti-nesting

    22 method is used to avoid multiple inclusion of headers: for example, </p> </li>

    23 </ul> <codeblock id="GUID-744E1BA3-112B-5F0E-9A41-82AD6A1B7C00" xml:space="preserve">// EG.H

    20 #endif</codeblock> </section> <section><title>Class layout</title> <p>Symbian OS 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>

    31 #endif</codeblock> </section>

    32 <section id="GUID-342D5A59-8489-495C-B619-48FF24B11029"><title>Class layout</title> <p>Symbian

    33 code uses the following conventions for laying out class declarations: </p> <p><b>General</b> </p> <ul>

    34 <li id="GUID-46510CC9-C7B0-528E-BB68-7A64BFC7BC61"><p>access control specifiers

    35 are always given for readability </p> </li>

    36 <li id="GUID-5EEB5EDA-848E-55C4-A9E8-8DDFE3091A01"><p>class members are declared

    37 in the following order: public member functions, protected member functions,

    38 private member functions, protected data, private data, public data. The appropriate

    39 access specifier is given at the start of each group. </p> </li>

    40 <li id="GUID-4A576792-75EA-543A-A6B4-B5357E4AE850"><p>for readability, function

    41 arguments are named in the function declaration as well as the definition </p> </li>

    42 </ul> <p><b>Virtual

    43 functions</b> </p> <ul>

    44 <li id="GUID-A66F4D3B-B259-59D8-9519-E173E4071015"><p>virtual functions that

    45 replace inherited behaviour are grouped together in the header, with a comment

    46 documenting from which class the behaviour is inherited </p> </li>

    47 <li id="GUID-16B867BB-7612-5D89-8E8E-947645EB3677"><p>the <codeph>virtual</codeph> keyword

    48 is not given for these functions </p> </li>

    49 <li id="GUID-42B49550-7AEE-5E30-825C-5F17F5DBB300"><p>virtual functions are

    50 not made inline, as it is difficult to know exactly how a compiler treats

    51 these. The exception to this are virtual inline destructors, which are allowed. </p> </li>

    52 </ul> <p><b>Inline

    53 functions</b> </p> <ul>

    54 <li id="GUID-00EEDE0A-3BC8-5359-B82A-7E864713F63E"><p>specify <codeph>inline</codeph> explicitly

    55 for inline functions. </p> </li>

    56 <li id="GUID-C0F56E55-A81D-578F-8605-6FF7A1ACB7A5"><p>do not provide the implementation

    57 in the class declaration. Instead, implementations are provided at the bottom

    58 of the header or in a separate <filepath>inl</filepath> file. </p> </li>

    59 </ul> </section>

    60 </conbody></concept>