Editing C++ Code Style Guide

We have legacy and new code. fixes of the legacy, which are small patches actually, adhere to the enclosing style.
For new code, see below.

== Naming Conventions ==

# Names should be readable, better to do not use abbreviations
# [https://en.wikipedia.org/wiki/CamelCase CamelCase] for names. Class, namespace, enum names should start with uppercase (for example, Audit). Other names should start with lowercase (Audit->getValue())
# Typedefs should have "_t" or "_type" suffix (myFavoriteType_t)
# Member value should have "m_" prefix (m_store)
# Static member variable should have "s_" prefix (s_count)
# Global object should have "g_" prefix. Global static variable is global still -> "g_" prefix
# No value type hints in a variable name or return type hints in a function name
# Local variables names should be short
# Class and namespaces names should consist of 1 or 2 words (Audit, AuditValue, but not AuditValueForTransition)
# Function name should start with a verb, because any function implies an action (getValue())
# Accesser name should start with "get", mutator name should start with "set" (getValue()/setValue())

== Formatting Conventions ==

# It is highly desirable to follow the restrictions:
## line length is below 80 symbols,
## function body (outer) is below 50 lines
# '{' is on the same line with "if", "for", "while"
# Single-line nested block - without braces
# There should be a C++-style comment ("// comment") at:
## closing '}' for a namespace should have a comment about the namespace
## #else, #endif, #elif - a comment about a condition of the very first #ifdef
# One operation (ended by ';') per line
# Preferred order of a class labeled sections inside the class declaration:
## public
## protected
## private
# Preferred order inside a section:
## typedefs
## constructors
## destructor
## member functions
## static functions
## member variables
## static variables
# Empty line after every section inside a class declaration
# No empty line after the last section inside a class declaration
# No indent inside namespace
# Header files:
## No "using namespace ..." inside header files
## if a header file is a part of public API:
### use 'extern "C"' construct
### comments for doxygen MUST be

== Taboos ==

# We do not use RTTI (no dynamic_cast<>)
# We do not use exceptions
# We do not use conversion operators (int())
# We do not use polymorphic inheritance
# We do not use assembler inlines
# We do not use "friends"
# We do not use "public" or "protected" member variables
# We do not use standalone functions (not bound to some class)

== Other Rules ==

# A function, which results only in a success or failure, should use 'boolean' return type. In a case of "success", it should return "true".
# A function, which results in a custom error, should return PRL_RESULT return type.
## For a successful result, use PRL_ERR_SUCCESS
## A check of successful result of this value should be performed by PRL_SUCCEEDED() or PRL_FAILED() macros.  
# It is highly desirable to avoid function definitions with more than 3 arguments. Allowed exceptions - external callbacks, interfaces, legacy functions.
# Use references to objects rather than pointers, even for smart pointers. 
# Group related classes to a single namespace
# If possible, avoid manual memory management (use of "new" and "delete" operators)
# If possible, avoid low-level thread management API ("pthread_xxx"), better to use boost or QT wrappers over it.
# Use anonymous namespace for symbols, which should be defined and used only inside a local compilation unit.
# If possible, avoid use of complex boolean conditions. '==' is better than '!=', '<' is better than '>='
# We do not welcome a function with a boolean argument, which changes the function's behaviour