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