TiGL Programmers Guide

TiGL programmer's guide

TiGL Mandatory C++ Style Guidelines

Tabs and Indentation

• Use 4 spaces indentation. Don't use tabs!
• Exceptions:
• public/protected/private keywords in class definitions
• namespace tigl

namespace tigl
{
namespace foo
{
    namespace bar 
    {
        /**some code**/
    }
}
}

Definitions and Declarations

• Braces in new lines:

class CCPACSWingProfiles
{

private:
    double _member;
}

• If you use several lines for a functions definition/declaration, align the function arguments horizontally

TIGL_COMMON_EXPORT TiglReturnCode tiglWingGetSegmentSurfaceArea(TiglCPACSConfigurationHandle cpacsHandle,
                                                                int wingIndex,
                                                                int segmentIndex,

Loops, If and Switch Statements

• space before and after condition
• Braces in the same line

if (psi.size()<=2) {
    psi.clear();
}
else {
    double psimax = psi[}

for (size_t i = 0; i < psi.size(); i++) {
    CTiglPoint* point1 = new CTiglPoint(psi[i](psi.size()-1];), 0.0, cstcurve(upperN1, upperN2, upperB, psi[i]));
}

switch (GetSymmetryAxis()) {
case TIGL_X_Y_PLANE:
    return zmax - zmin;
case TIGL_X_Z_PLANE:
    return ymax - ymin;
}

Automatic code formatting to TiGL style guide

There is a nice code format tool, called Artistic Style (http://astyle.sourceforge.net/). It can be completely adapted to the TiGL style guidelines. The best of the tool is, that it only reformats the lines that don't match the style guidelines. Thus, it keeps manual formatting intact.

The following options should be used:

--style=kr      
--break-closing-brackets
--add-brackets
--indent=spaces=4
--align-pointer=type
--align-reference=type

The Beautifier plugin shipped with QtCreator supports Artistic Style, so you will be able to automatically format your code.

Remember: These code style guidelines are mandatory!!!

Git usage guidelines

Use proper commits messages for automatic change log creation

During the Tigl Release Guide, the commit messages are parsed and separated into five categories in order to create a change log file in restructured text format automatically. Afterwards, this file is converted to Latex and Google code wiki syntax. You should choose your commit message such, that it is correctly classified. For example the following commit message:

"Changed API function CCPACSWingGetPoint"

should be classified under the category "Changed API". The five categories and the corresponding filters are

**Category**	**Filter**	**Buzzwords**	**Example**
Changed API	Contains **all** buzzwords (case insensitive)	'changed', 'api'	``Changed API function CCPACSWingGetPoint``
New API	Contains **all** buzzwords (case insensitive)	'new', 'api'	``New API function CCPACSWingGetPoint``
Fixes	Contains any of the buzzwords (case insensitive)	'fixes', 'fixed', 'bugfix', 'bugfixes', 'fix'	``Fixed bug in CCPACSWingGetPoint``
TiGLViewer	Contains the buzzword (case insensitive, this filter superseeds all other filters)	'tiglviewer'	``New API function in TiGLViewer``
General Changes	Does not belong to the other categories		``Added support for VTK export``

Moreover, file names and code should be displayed in monospaced fonts. This is achieved by the following filter

Filter	Buzzwords
prefix	'tixi', 'tigl', 'CCPACS', 'ITigl', 'CTigl'
suffix	'.sh', '.cpp', '.h', '.py', '.txt', '.tex'
contains but is not equal	'Wing', 'Fuselage'

For example the message

Changed behaviour of CCPACSWingProfile::GetUpperWire() in CCPACSWingProfile.cpp

is converted into

Changed behaviour of CCPACSWingProfile::GetUpperWire() in CCPACSWingProfile.cpp

General git guidelines

• Use a separate branch for each feature. Merge the feature branch into master after finishing feature development.
• Don't force git pushes (git push -f). Forcing push is evil and will probably cause armageddon. Only use, if you REALLY know what you're doing.