As far as I understand, sonar doesn’t have a specific mechanism to figure out which files are headers and which files are sources when analyzing c or c++ code.
When using SonarLint that quite often confuses the analyzer when having header files open, causing warnings that are meant for source files.
I now relalized that there’s another case where Sonar emits warnings based on the wrong assumptions about what kind of file it’s analyzing.
Functionally, we have a file that looks like this for the purpose of having code specific for Windows and Unix based systems without mixing it in the same file with mor preprocessor directives than necessary.
#ifdef _WIN32 #include "file_for_windows.cpp" #else #include "file_for_unix.cpp" #endif
Obviously this emits a warning about using #include on a cpp file. We cover that with
// NOSONAR. But the bigger challenge seems to be that the analyzer will now treat “file_for_windows.cpp” as a header file because it was included to the translation unit with
#include. The effect is that rules such as this can trigger.
It would be convenient to identify files as headers or sources based on the file extensions.