Differences

This shows you the differences between two versions of the page.

--- coding_style [2017/10/21 11:30] – [Python] damien
+++ coding_style [2018/05/22 10:33] – external edit 127.0.0.1
@@ Line 1: / Line 1: @@
+====== General rules ======
+  * All code and documentation is written in English.
+  * Maximum line length should be 100 characters
+====== C/C++ ======
+===== Indentation =====
+  * 4 spaces
+  * No tabs !
+===== Names =====
+  * 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();''
+===== File names =====
+  * 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
+<code cpp MyClass.hpp>
+#ifndef MY_CLASS_HPP__
+#define MY_CLASS_HPP__
+class MyClass
+{
+public:
+    MyClass();
+    ~MyClass();
+    void do();
+};
+#endif
+</code>
+<code cpp MyClass.cpp>
+#include "MyClass.hpp"
+MyClass::MyClass()
+{
+}
+MyClass::~MyClass()
+{
+}
+void MyClass::do()
+{
+    // do something
+}
+</code>
+  * For all other cases, use lowercase-with-underscore filenames.
+===== C headers =====
+Protect your C headers for C++ inclusions:
+<code cpp my_header.h>
+#ifndef MY_HEADER_H__
+#define MY_HEADER_H__
+#ifdef __cplusplus
+extern "C"
+{
+#endif
+void unit_myFunction(void);
+#ifdef __cplusplus
+}
+#endif
+#endif
+</code>
+===== Braces =====
+  * Curly braces go on their own line
+<code cpp>
+if ( a == b )
+{
+    // do something
+}
+</code>
+  * Use curly braces even for one-line blocks
+  * Use parentheses even when precedence of operators applies
+===== Documentation =====
+  * Use Doxygen syntax ( http://www.stack.nl/~dimitri/doxygen/manual/docblocks.html )
+  * Prefer self-explanatory names over extended comments.
+====== Python ======
+  * Respect the PEP8 guidelines:
+    * https://www.python.org/dev/peps/pep-0008/ (official)
+    * http://sametmax.com/le-pep8-en-resume/ (summary)
+====== Abbreviations ======
+Do not overuse abbreviations and acronyms to keep the code clear.
+However for common and well known names, use below table.
+^ Abbreviation ^ Meaning ^
+| cbf | Callback Function |
+| ptr | Pointer |
+====== Recommended external libraries ======
+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.
+===== 0MQ =====
+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).
+===== python3 =====
+Whenever possible use python3 instead of python2.
+When writing Python code, make sure it is python3 compatible.
+===== Google Test =====
+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.
+===== Qt5 =====
+http://www.qt.io/
+When developing graphical applications, prefer Qt or one of its bindings (like PyQt).
+===== Herqq UPnP =====
+http://hupnp.linada.fi/
+A standard-compliant UPnP library to build devices and control points.