• All code and documentation is written in English.
• Maximum line length should be 100 characters

A Gerrit repository contains formatter configuration profiles compatible with Eclipse and Visual Studio. Refer to the attached README to know how to use them.

An Eclipse configuration file is available in the Quimesis Drive ( 06 Documentation > Doc info > quimesis_coding_rules_for_eclipse.xml); refer to the Development environment document in the same directory for how to use it.

• 4 spaces
• No tabs !

• Variables or member functions are camel-case, starting with a lower-case letter
• Classes and structs names start with an upper-case letter
• #defines and values of an enum are all-capitals
• namespaces are lower-case
• In C, prefix the function names with a pseudo-namespace/unit name. e.g.: MyUnit_init();

• Use .c extension when the unit should be compiled with a C compiler (gcc)
• Use .cpp extension when the unit should be compiled with a C++ compiler (g++)
• In C++, use one .hpp/.cpp per class, with the files having the name of the class

MyClass.hpp

#ifndef MY_CLASS_HPP__
#define MY_CLASS_HPP__
 
class MyClass 
{
public:
    MyClass();
    ~MyClass();
 
    void do();
};
 
#endif

MyClass.cpp

#include "MyClass.hpp"
 
MyClass::MyClass()
{
}
 
MyClass::~MyClass()
{
}
 
void MyClass::do()
{
    // do something
}

• For all other cases, use lowercase-with-underscore filenames.

Protect your C headers for C++ inclusions:

my_header.h

#ifndef MY_HEADER_H__
#define MY_HEADER_H__
 
#ifdef __cplusplus
extern "C"
{
#endif
 
void unit_myFunction(void);
 
#ifdef __cplusplus
}
#endif
 
#endif

• Curly braces go on their own line

if ( a == b ) 
{
    // do something
}

• Use curly braces even for one-line blocks
• Use parentheses even when precedence of operators applies

• Use Doxygen syntax ( http://www.stack.nl/~dimitri/doxygen/manual/docblocks.html )
• Prefer self-explanatory names over extended comments.
• README files could be necessary; in which case it is recommended to use Markdown for its formatting

• Respect the PEP8 guidelines:
  • https://www.python.org/dev/peps/pep-0008/ (official)
  • http://sametmax.com/le-pep8-en-resume/ (summary)

Do not overuse abbreviations and acronyms to keep the code clear. However for common and well known names, use below table.

Here is a list of well known libraries that provide various kinds of functionalities. Whenever you need one of them, prefer to use the below library so that we keep a uniform code-base.

http://zeromq.org/

ZeroMQ, and its multiple bindings like py-zmq, is a transport layer for inter-process, inter-tasks, inter-node communications. It supports various paradigms of communications ( requests-response, push-pull, publish-subscribe, etc) and handles most of the network complexity (like reconnections, data integrity, etc).

Whenever possible use python3 instead of python2.

When writing Python code, make sure it is python3 compatible.

https://code.google.com/p/googletest/

Google Test is a test framework for C/C++. It is the recommended way to write Unit Tests for C++ code.

http://www.qt.io/

When developing graphical applications, prefer Qt or one of its bindings (like PyQt).

http://hupnp.linada.fi/

A standard-compliant UPnP library to build devices and control points.

http://mosquitto.org/

Ubuntu package to install: libmosquitto-dev

https://github.com/open-source-parsers/jsoncpp

Ubuntu package to install: libjsoncpp-dev

http://libserial.sourceforge.net/

Ubuntu package to install: libserial-dev

• switch case indentation:

switch(<var>)
{
    case <value>:
    {
        <code>
        break;
    }
}