Date: Fri, 29 Mar 2024 12:45:24 +0000 (UTC) Message-ID: <2037525903.1.1711716324028@e44425484846> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_0_1440625333.1711716324014" ------=_Part_0_1440625333.1711716324014 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
This document defines and formalizes the presentation and redaction of a= ll source files. A strict adherence to these conventions is required to ens= ure a readable and understandable code.
There are very few restrictions on file names and locations. The followi= ng rules are expected:
A quick check of the source directory will show how files are organized = within the source tree. The sources are organized in two levels.
The first level specifies which part of the platform the source belongs = to:
The second level specifies the types of data:
or
NOTE: The directory include only contains public headers, if you have pr= ivate headers put them in src.
The third level specifies which logica= l part the file belongs to:
This applies to basic source as well as include files, who are in a sepa= rate include tree and never along their source code files. Thus, an include= declaration would be:
#include= "nel/misc/steam.h"
All code files must begin with a specific header. The model of that head= er is defined in headers.txt in the documentation directory. It is recommen= ded that people include that file immediately when starting a new file.
Integral Types
Examples: uint8 (unsigned 8 bit integer), sint64 (signed 64 bit integer)= , sint (signed integer of at least 32 bits)
As a general rule, the classic and sloppy use of short / int / long is&n= bsp;proscribed, as is using a char&n= bsp;to represent a 8-bit number, unless this is required to call an externa= l API. a char should use only when you want to r= epresent a ASCII character.
All elements will be in their own namespace, which is short, in all uppe= rcase, and consist of a two letter code (NL for NeL), followed by the direc= tory name. Thus an element of the NeL 3D library will be declared in the NL= 3D namespace.
The following conventions are applied to names within these namespaces:<= /p>
Note that there is no difference between variables and constants.
A strong suggestion is to set your tabulation marks to 4 characters, rat= her than the usual 8. Indentation is always done using tabulations, never w= ith spaces. Make sure your text editor does not replace tabulations with sp= aces.
If possible, function, members and variable lists should align the first= character of all their names.
Source code is written using a flat style. In this style, the opening an= d closing curly braces are placed on separate lines (never with code), and = at the same indentation as the preceding defining element, while the conten= t of the block enclosed between the braces is indented once from the source= . Your code source should look like this:
class CD= ummy { void dummy (uint32 b) { if (b =3D=3D 0xDEADBEEF) { // ... } } };
Comments may use either the C++ style comments //, or the more classic C= commenting method. If possible the source must be heavily commented and as= many comments as possible must conform to the Doxygen commenting methods s= o that they can be extracted and reused as software documentation.
Comment "separators" will be made with a line of repeated star '*' chara= cters. You should not use more than 50 stars to separate.
The practice of comment blocks, comments where each line begins and end =
with a star character, to create a "text block" is proscribed.
Final Coding Recommendations
Even if most of these are obvious recommendations, it is useful to resta= te these basic principles: