diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index fdd306c..1a6f9ca 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -1,7 +1,6 @@
 Guidelines for Developing and Contributing Code
 ===============================================
 
-
 Table of Contents
 -----------------
 
@@ -20,13 +19,11 @@ Table of Contents
   - Example
 5. Porting
 
-
 1. Introduction
 ---------------
 
 The EMB² team welcomes all kinds of feedback and contributions. Please don't hesitate to contact us if you have any questions, comments, bug reports, suggestions for improvement, extensions or the like (see [README.md](https://github.com/siemens/embb/blob/master/README.md) for general contact information). In the following, we give an overview of the development environment as well as coding and documentation guidelines, and sketch how to port EMB² to other platforms.
 
-
 2. Development Environment
 --------------------------
 
@@ -60,8 +57,8 @@ If you add a directory, e.g., for a new plugin, please don't forget to update al
 
 There are two predefined branches in the Git repository:
 
-- ```master```: This branch contains the latest stable version of EMB², i.e., the source code has been reviewed and all tests pass successfully.
-- ```development```: Implementation takes place in this branch. In contrast to feature branches (see below), the source code in this branch has to be compilable. When new features are stable, the development branch is merged back into the master branch.
+- `master`: This branch contains the latest stable version of EMB², i.e., the source code has been reviewed and all tests pass successfully.
+- `development`: Implementation takes place in this branch. In contrast to feature branches (see below), the source code in this branch has to be compilable. When new features are stable, the development branch is merged back into the master branch.
 
 In addition to these two branches, there may be arbitrarily many feature branches for implementing new functionality or fixing bugs. There are no requirements on the source code in these branches. After finishing the implementation, a feature branch is merged into the development branch (make sure that the source code is still compilable afterwards).
 
@@ -69,7 +66,6 @@ In addition to these two branches, there may be arbitrarily many feature branche
 
 Bug fixes, extensions, etc. can be contributed as pull requests via GitHub or as patches via the development mailing list (mailto:embb-dev@googlegroups.com). If possible, please refer to a current snapshot of the master branch.
 
-
 3. Coding Guidelines
 --------------------
 
@@ -79,32 +75,32 @@ Bug fixes, extensions, etc. can be contributed as pull requests via GitHub or as
 queue, for example, shall only allocate memory in the constructor but not during
 operation, i.e., in the methods for pushing and popping elements.
 - Use assertions to catch bugs (always think what could theoretically happen).
-- Use exceptions to catch invalid user input (by the ```EMBB_THROW``` macro).
+- Use exceptions to catch invalid user input (by the `EMBB_THROW` macro).
 - Use concepts instead of interfaces unless virtual functions are necessary.
-- Use ```const``` whenever it makes sense.
-- Use pointers only if they can be ```NULL```, otherwise use const/non-const references.
-- Use ```size_t``` if the number of elements, indices, etc. depends on a pointer (```size_t``` has the same size as a pointer).
-- For iterators, use ```first``` and ```last``` (as in STL), not ```begin``` and ```end```.
+- Use `const` whenever it makes sense.
+- Use pointers only if they can be `NULL`, otherwise use const/non-const references.
+- Use `size_t` if the number of elements, indices, etc. depends on a pointer (`size_t` has the same size as a pointer).
+- For iterators, use `first` and `last` (as in STL), not `begin` and `end`.
 - Use the same order of functions etc. in the source files as in the corresponding header files.
 - Be aware of false sharing and align objects when appropriate.
 - Disable construction, copy construction, and assignment whenever it makes sense by declaring the corresponding functions private without giving a definition.
-- For headers, use ```#include <...>``` instead of ```#include "..."```.
-- Include paths have the format ```#include <embb/component_name/...>```, e.g., ```#include <embb/base/internal/some_header.h>```.
-- In C code, use the prefix ```embb_component_``` for globally visible symbols. For example, the thread creation function is named ```embb_base_ThreadCreate```.
-- Similarly, use the prefix ```EMBB_COMPONENT_``` for preprocessor macros.
+- For headers, use `#include <...>` instead of `#include "..."`.
+- Include paths have the format `#include <embb/component_name/...>`, e.g., `#include <embb/base/internal/some_header.h>`.
+- In C code, use the prefix `embb_component_` for globally visible symbols. For example, the thread creation function is named `embb_base_ThreadCreate`.
+- Similarly, use the prefix `EMBB_COMPONENT_` for preprocessor macros.
 
 ### Tool Support
 
 - All source files in the repository must have LF (Unix) line endings. Git can take care of this (using the following option, newly checked-in files and changes to them will automatically be converted from CRLF to LF if necessary):
-```
+
   git config --global core.autocrlf input
-```
-- For the C++ parts of EMB², we follow [Google's C++ style guide](https://google.github.io/styleguide/cppguide.html) which can be checked using the [cpplint](https://raw.githubusercontent.com/google/styleguide/gh-pages/cpplint/cpplint.py) tool. However, we ignore some rules as they are not applicable or yield false results for this project. For example, we respect the include order of the Google style guide, but use <> instead of "" for project includes (see above). To check whether your code adheres to the style guide, use the ```run_cpplint.sh``` script containted in the ```scripts``` folder. You may use [clang-format](http://clang.llvm.org/docs/ClangFormat.html) with option ```-style=Google``` to pretty print your code but be aware that line breaking of Doxygen comments may not work properly.
+
+- For the C++ parts of EMB², we follow [Google's C++ style guide](https://google.github.io/styleguide/cppguide.html) which can be checked using the [cpplint](https://raw.githubusercontent.com/google/styleguide/gh-pages/cpplint/cpplint.py) tool. However, we ignore some rules as they are not applicable or yield false results for this project. For example, we respect the include order of the Google style guide, but use <> instead of "" for project includes (see above). To check whether your code adheres to the style guide, use the `run_cpplint.sh` script containted in the `scripts` folder. You may use [clang-format](http://clang.llvm.org/docs/ClangFormat.html) with option `-style=Google` to pretty print your code but be aware that line breaking of Doxygen comments may not work properly.
 - Moreover, we regularly check the code using [Cppcheck](http://cppcheck.sourceforge.net/), a light-weight static analysis tool for C/C++. To run Cppcheck on all files in a certain directory, call it as follows:
 ```
   cppcheck --enable=warning,style,performance,portability --inconclusive <directory>
 ```
-- We do not accept compiler warnings with a few exceptions when using MSVC (see below). By default, warnings are enabled using ```-Wall -Wextra``` (GCC) or ```/Wall``` (MSVC). To make sure that no warnings are overlooked, you can treat warnings as errors by setting ```WARNINGS_ARE_ERRORS``` to ```ON```, for example:
+- We do not accept compiler warnings with a few exceptions when using MSVC (see below). By default, warnings are enabled using `-Wall -Wextra` (GCC) or `/Wall` (MSVC). To make sure that no warnings are overlooked, you can treat warnings as errors by setting `WARNINGS_ARE_ERRORS` to `ON`, for example:
 ```
   cmake -g "Unix Makefiles" .. -DWARNINGS_ARE_ERRORS=ON
 ```
@@ -121,7 +117,6 @@ operation, i.e., in the methods for pushing and popping elements.
 #endif
 ```
 
-
 4. Documentation Guidelines
 ---------------------------
 
@@ -135,38 +130,38 @@ The source code is documented using [Doxygen](http::www.doxygen.org/). Please ad
 - Enable spell checking in your IDE and proofread the documentation generated by Doxygen.
 - Use full stops at the end of complete sentences (and only there).
 - The first sentence ending with a full stop is parsed as brief description by Doxygen.
-- Use ```\``` instead of ```@``` for Doxygen commands.
-- Typeset code fragments including constants such 'true' and 'false' in typewriter font using ```\c``` (example: ```returns \c true if ...```).
-- Use ```<tt>...</tt>``` instead of ```\c``` for complex expressions that include, for example, braces (otherwise, the code might not be formatted correctly).
-- Use ```@code``` for multiple lines of code (examples etc.).
-- Document parameters in place (after the parameter) using ```/**< [in,out,in/out] ... documentation ... */```
-- Refer to functions by adding braces after the name (example: ```Fun()``` but not just ```Fun```).
-- Explicit or implicit dynamic memory allocation must be documented using the ```\memory``` command (see below).
+- Use `\` instead of `@` for Doxygen commands.
+- Typeset code fragments including constants such 'true' and 'false' in typewriter font using `\c` (example: `returns \c true if ...`).
+- Use `<tt>...</tt>` instead of `\c` for complex expressions that include, for example, braces (otherwise, the code might not be formatted correctly).
+- Use `@code` for multiple lines of code (examples etc.).
+- Document parameters in place (after the parameter) using `/**< [in,out,in/out] ... documentation ... */`
+- Refer to functions by adding braces after the name (example: `Fun()` but not just `Fun`).
+- Explicit or implicit dynamic memory allocation must be documented using the `\memory` command (see below).
 
 ### Special Commands
 
 Use special commands to specify properties important in embedded systems:
 
-- ```\memory```: Use if and only if a function/method dynamically allocates memory. Give a short comment and optionally specify the asymptotic memory consumption.
-- ```\notthreadsafe```, ```\threadsafe```, ```\lockfree```, ```\waitfree```: Always use one (!) of these commands to specify the behaviour related to concurrent execution. Note that ```\lockfree``` includes ```\threadsafe``` and ```\waitfree``` includes ```\lockfree```.
-- ```\threadsafe``` means that a shared state (e.g., the member variables of an object, but also pointers/references passed as arguments to a function) is accessed in a synchronized way. This implies that a C function that gets ```const``` pointers as arguments is not thread-safe if there are other functions that can modify the arguments concurrently. Similarly, if a method doesn't modify the state of an object, but other methods are able to do so, the method is not thread-safe.
-- ```\lockfree``` means that at least one thread is always guaranteed to make progress, and ```\waitfree``` means that all threads are guaranteed to always make progress. A more detailed classification can be found in "M. Herlihy and N. Shavit. *On the nature of progress*. Principles of Distributed Systems (OPODIS'11), Springer-Verlag, 2011".
+- `\memory`: Use if and only if a function/method dynamically allocates memory. Give a short comment and optionally specify the asymptotic memory consumption.
+- `\notthreadsafe`, `\threadsafe`, `\lockfree`, `\waitfree`: Always use one (!) of these commands to specify the behaviour related to concurrent execution. Note that `\lockfree` includes `\threadsafe` and `\waitfree` includes `\lockfree`.
+- `\threadsafe` means that a shared state (e.g., the member variables of an object, but also pointers/references passed as arguments to a function) is accessed in a synchronized way. This implies that a C function that gets `const` pointers as arguments is not thread-safe if there are other functions that can modify the arguments concurrently. Similarly, if a method doesn't modify the state of an object, but other methods are able to do so, the method is not thread-safe.
+- `\lockfree` means that at least one thread is always guaranteed to make progress, and `\waitfree` means that all threads are guaranteed to always make progress. A more detailed classification can be found in "M. Herlihy and N. Shavit. *On the nature of progress*. Principles of Distributed Systems (OPODIS'11), Springer-Verlag, 2011".
 
 ### Structure
 
 The following sequence of descriptions and commands shall be obeyed to achieve a consistent layout of the documentation:
 
-1. Brief description ending with a full stop (without ```\brief```)
+1. Brief description ending with a full stop (without `\brief`)
 2. More detailed description [optional]
-3. ```\pre```: Preconditions that must hold when calling the function [optional]
-4. ```\post```: Postconditions that holld after calling the function [optional]
-5. ```\return```: Description of return value [optional]
-6. ```\throws```: Thrown exceptions (repeat for each exception) [optional]
-7. ```\memory```: Dynamic memory allocation (see above) [optional]
-8. ```\notthreadsafe```, ```\threadsafe```, ```\lockfree```, ```\waitfree```: Thread safety and progress guarantees (see above)
-9. ```\note```: Additional notes/comments [optional]
-10. ```\see```: Links to other related functions, types, etc. [optional]
-11. ```\tparam```: Template parameters [optional]
+3. `\pre`: Preconditions that must hold when calling the function [optional]
+4. `\post`: Postconditions that holld after calling the function [optional]
+5. `\return`: Description of return value [optional]
+6. `\throws`: Thrown exceptions (repeat for each exception) [optional]
+7. `\memory`: Dynamic memory allocation (see above) [optional]
+8. `\notthreadsafe`, `\threadsafe`, `\lockfree`, `\waitfree`: Thread safety and progress guarantees (see above)
+9. `\note`: Additional notes/comments [optional]
+10. `\see`: Links to other related functions, types, etc. [optional]
+11. `\tparam`: Template parameters [optional]
 
 ### Example
 
@@ -209,11 +204,10 @@ class Queue {
 };
 ```
 
-
 5. Porting
 ----------
 
-EMB² is easily portable to platforms unsupported so far. Almost all platform specific code is located in the ```base_c``` and ```base_cpp``` directories, and platform specific code is fenced using ```EMBB_PLATFORM_*``` defines.
+EMB² is easily portable to platforms unsupported so far. Almost all platform specific code is located in the `base_c` and `base_cpp` directories, and platform specific code is fenced using `EMBB_PLATFORM_*` defines.
 
 To distinguish between compilers, EMB² currently uses the following defines:
 
@@ -234,6 +228,6 @@ Threading APIs are switched by:
 - EMBB_PLATFORM_THREADING_WINTHREADS
 - EMBB_PLATFORM_THREADING_POSIXTHREADS
 
-Please use these defines for new platform specific code. If additional defines are needed, they can be included in the ```config.h``` or ```cmake_config.h.in``` files.
+Please use these defines for new platform specific code. If additional defines are needed, they can be included in the `config.h` or `cmake_config.h.in` files.
 
 A list of macros to check the underlying platform, compiler versions, etc. can be found here: http://sourceforge.net/p/predef/wiki/Home/