Coding-Conventions-and-Guidelines.md

@@ -184,7 +184,7 @@ Important rules, and notable differences are summarized here:
    Either you implement any of them (zero), or all of them (five); and if memory/resources must be released also         the destructor. 
    Instead of implementing, you may use the defaults ``` = default``` or ``` = delete``` keywords to indicate desired behavior. 
 
-- Each functional group of classes has a unit test ```testThis.cpp```
+- Each functional group of classes has a unit test ```testThis.cpp```. See [Guidelines for Unit Tests](Guidelines-for-Unit-Tests) for details. 
 - Adhere to C++17 standards. In particular:
    - Define public, private and protected type aliases and typedefs on the top, inside the class or 
      method they are
@@ -270,8 +270,8 @@ Important rules, and notable differences are summarized here:
 
 ## General Rules
 
-- Basically never use "iostream" cout, cerr, and endl. We use our own logging machinery based on spdlog.
-- Test your code with ```-pedantic``` compiler flag enabled. 
+- Basically never use "iostream" cout, cerr, and endl. We use our own logging machinery based on spdlog. See [Logging Guidelines](Logging-Guidelines).
+- Test your code with ```-pedantic``` compiler flag enabled. This is done automatically by the default CMakeLists.txt file.  
 - Warnings have to be fixed, when they appear on the system(s) currently used by the CI, by altering the code unless the warning originates from third-party code and cannot be fixed. In such cases, developers of the third-party project should be informed. Should the warning be locally silenced, either using appropriate pragmas or locally turning off warnings for that translation unit, documentation should be added in the entry point triggering the 
 warning using the flag ```"FIXME"``` as keyword.
 - All unit tests must succeed on the specified systems/configurations on gitlab-ci. If tests fail, code is not merged.  In certain cases, core developing team will consider to update or extend the CI systems.