Coding-Guidelines.md

 These are some rules and guidelines that we decided to adopt in order to write
-more readable and safe code.
+more readable and safe code: they were chosen after some trials and errors, so you
+will see that not all of the code in this repository  follows them, 
+yet it is very important that you keep them in mind when producing the software here.
 
-Following these rules is not *absolutely* necessary, and much of the existing code was written
-before we even decided them, but their use is definitely suggested.
-
-# **Coding Rules**
 You can find some good rules for writing safety-critical code here: <http://pixelscommander.com/wp-content/uploads/2014/12/P10.pdf>.
 
 The following rules take inspiration from the JSF - C++ Rules, which you can read here: <http://www.stroustrup.com/JSF-AV-rules.pdf>
@@ -23,7 +21,7 @@ Avoid undefined behavior where a derived class is destroyed through a reference
 - **Every header file shall be guarded using defines containing the full project path of the file**  
 Avoid conflicts when having files with the same name in multiple directories.  
 Example: File `src/shared/sensors/ExampleSensor.h`
-```
+```cpp
 #ifndef SRC_SHARED_SENSORS_EXAMPLESENSOR_H
 #define SRC_SHARED_SENSORS_EXAMPLESENSOR_H
 
@@ -80,7 +78,7 @@ Example: `class TemperatureSensor{};`
 - **Constants and enum members will be named using ALL_CAPS_WITH_UNDERSCORES**  
 Example 1: `float TEMPERATURE_SAMPLE;`  
 Example 2:  
-```
+```cpp
 enum class ExampleEnum {  
     EXAMPLE_MEMBER_1,  
     EXAMPLE_MEMBER_2  
@@ -90,7 +88,7 @@ enum class ExampleEnum {
 Example 1: `float pressure_sample;`
 - **Names of members of c-style enums shall begin with a identifier of the enum, to avoid ambiguities, since they are not scoped**  
 Example 2:  
-```
+```cpp
 enum EventIDs {  
     EV_ID_1,
     EV_ID_2