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

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